🔔 Event-Driven

Components communicate by producing and consuming events.

Traditional (request-response):
  Service A calls Service B directly.
  A waits for B's response.
  Tightly coupled.

Event-driven:
  Service A publishes "OrderPlaced" event.
  Services B, C, D consume it (if interested).
  A doesn't wait. A doesn't know who listens.
  Loosely coupled!

A record of something that happened.

{
  "type": "OrderPlaced",
  "timestamp": "<timestamp>",
  "data": {
    "orderId": "123",
    "userId": "456",
    "total": <total>
  }
}

Past tense! "OrderPlaced" not "PlaceOrder"
Immutable fact.

Service that publishes events.

Order Service → publishes "OrderPlaced"

Doesn't know or care who consumes.

Service that subscribes to events.

Inventory Service ← consumes "OrderPlaced"
Email Service ← consumes "OrderPlaced"
Analytics Service ← consumes "OrderPlaced"

Each handles the event independently.

Middleware that routes events.

Producers → Broker → Consumers

Examples: Kafka, RabbitMQ, AWS SNS/SQS

Order placed:

┌────────────┐
│   Order    │ ──→ "OrderPlaced" ──→ ┌───────────┐
│  Service   │                        │  Message  │
└────────────┘                        │  Broker   │
                                      └─────┬─────┘
                         ┌─────────────────┼─────────────────┐
                         │                 │                 │
                         ▼                 ▼                 ▼
                   ┌──────────┐     ┌──────────┐     ┌──────────┐
                   │Inventory │     │  Email   │     │Analytics │
                   │ Service  │     │ Service  │     │ Service  │
                   └──────────┘     └──────────┘     └──────────┘

Each service reacts independently.

One event → Multiple subscribers

OrderPlaced event:
  - Inventory: Reduce stock
  - Email: Send confirmation
  - Analytics: Record sale
  - Shipping: Create label

Add new subscriber without changing producer.

Continuous stream of events.
Consumers process in real-time.

Example: User activity stream
  Click → Scroll → Click → Purchase → ...

Kafka excels here.

Store events as source of truth.
Derive current state from event history.

(See Event Sourcing topic for details)

Producer doesn't know consumers.
Add/remove consumers freely.
Services can be developed independently.

Consumers can process events at their own pace.
High volume? Add more consumer instances.
Broker buffers when consumers are slow.

Service down? Events wait in broker.
Service recovers? Processes backlog.
Less chance of data loss (when the broker is configured for durability).

Events propagate immediately.
Systems react in real-time.
Analytics, notifications, automation.

Events take time to propagate.
Consumer may be slightly behind producer.

Not a problem for most cases.
Challenge for strict consistency needs.

Request-response: Clear call chain.
Event-driven: Events scatter across services.

Need distributed tracing.
Need event correlation IDs.

Events may arrive out of order.
Consumer should handle, or the broker should provide ordering guarantees.

Partitioning can help (Kafka).

Events change over time.
Old consumers, new events. New consumers, old events.

Need versioning strategy.

✓ Microservices needing to communicate
✓ Real-time data processing
✓ Async operations (email, notifications)
✓ Multiple services react to same event
✓ Scaling read/write independently

✗ Simple CRUD applications
✗ Strong consistency requirements
✗ Single service applications
✗ Tight request-response needs

Event with entire object:
  { "order": { ...full order object... } }

Better: Include IDs, consumer fetches if needed.
Or: Just enough data for consumer's needs.

Producer changes event format.
Consumer breaks.

Define schemas (Avro, Protobuf, JSON Schema).
Version events.

Event processing fails.
Event discarded.
Data lost!

Use dead letter queues.
Retry with backoff.
Alert on failures.