What is event-driven architecture in microservices?

Question

Accepted Answer

In an **event-driven architecture**, services communicate by **producing and consuming events** through a broker (Kafka, RabbitMQ, etc.). A service announces that something happened; interested services react — the producer doesn't know or wait for them.

## How it works

```text
Order Service ─publish→ [ Event Broker: "order.placed" ]
                              │
            ┌─────────────────┼──────────────────┐
            ▼                 ▼                  ▼
      Inventory         Notification          Analytics
      (reserve stock)   (send email)          (record metric)
```

## Event payload example

```json
{
  "eventType": "order.placed",
  "eventId": "e-9f2c",          // unique → consumers dedupe
  "occurredAt": "2026-06-18T10:00:00Z",
  "data": { "orderId": "42", "total": 99.5 }
}
```

## Benefits

- **Loose coupling** — add a new consumer without touching the producer.
- **Resilience** — the broker buffers events during outages.
- **Scalability** — consumers scale independently.

## Pitfalls

```text
⚠️ Eventual consistency — readers may briefly see stale data
⚠️ Duplicate delivery — make consumers idempotent (use eventId)
⚠️ Ordering — only guaranteed within a partition/queue
⚠️ Hard to trace a flow across many consumers
```

## Why it matters

Event-driven design is what lets you add capabilities (analytics, fraud checks, notifications) by simply subscribing, with zero changes to existing producers.

That extensibility and resilience come at the price of eventual consistency and harder debugging — the central trade-off you accept when going event-driven.