Was ist Event-driven Architecture in Microservices?

Question

Accepted Answer

In einer **Event-driven Architecture** kommunizieren Services durch **Erzeugung und Verbrauch von Events** über einen Broker (Kafka, RabbitMQ etc.). Ein Service teilt mit, dass etwas passiert ist; interessierte Services reagieren — der Producer kennt sie nicht und wartet nicht auf sie.

## Wie es funktioniert

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

## Beispiel für Event-Payload

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

## Vorteile

- **Lose Kopplung** — fügen Sie einen neuen Consumer hinzu, ohne den Producer zu ändern.
- **Resilienz** — der Broker puffert Events während Ausfällen.
- **Skalierbarkeit** — Consumer skalieren unabhängig.

## Fallstricke

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

## Warum es wichtig ist

Event-driven Design ermöglicht es Ihnen, Funktionen (Analysen, Betrugsprüfungen, Benachrichtigungen) durch einfaches Abonnieren hinzuzufügen, ohne bestehende Producer zu verändern.

Diese Erweiterbarkeit und Resilienz kommen auf Kosten von eventueller Konsistenz und schwierigeres Debugging — der zentrale Kompromiss, den Sie bei Event-driven eingehen.