Wat is event-driven architecture in microservices?

Question

Accepted Answer

In een **event-driven architecture** communiceren services door **events te produceren en te consumeren** via een broker (Kafka, RabbitMQ, enz.). Een service kondigt aan dat iets is gebeurd; geïnteresseerde services reageren — de producent weet niet of wacht niet op hen.

## Hoe het werkt

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

## Voorbeeld van event payload

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

## Voordelen

- **Losse koppeling** — voeg een nieuwe consumer toe zonder de producent aan te raken.
- **Veerkracht** — de broker buffert events tijdens storingen.
- **Schaalbaarheid** — consumers schalen onafhankelijk.

## Valkuilen

```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
```

## Waarom het belangrijk is

Event-driven design stelt je in staat om mogelijkheden (analytics, fraudecontrole, meldingen) toe te voegen door gewoon in te schrijven, zonder wijzigingen aan bestaande producenten.

Die uitbreidbaarheid en veerkracht hebben de prijs van uiteindelijke consistentie en moeilijkere debugging — de centrale afweging die je aanvaardt wanneer je event-driven gaat.