Hvad er event-driven arkitektur i mikroservices?

Question

Accepted Answer

I en **event-driven arkitektur** kommunikerer services ved at **producere og konsumere events** gennem en broker (Kafka, RabbitMQ osv.). En service annoncerer, at noget er sket; interesserede services reagerer — producenten ved ikke eller venter ikke på dem.

## Sådan fungerer det

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

## Eksempel på event payload

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

## Fordele

- **Løs kobling** — tilføj en ny consumer uden at røre producenten.
- **Modstandsdygtighed** — brokeren bufrer events under nedbrud.
- **Skalerbarhed** — consumers skaleres uafhængigt.

## Faldgruber

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

## Hvorfor det betyder noget

Event-driven design er det, der gør det muligt at tilføje evner (analyser, svindelkontrol, notifikationer) ved blot at abonnere, uden ændringer i eksisterende producenter.

Denne udvidelsesmulighed og modstandsdygtighed kommer på bekostning af eventuel konsistens og vanskeligere debugging — det centrale kompromis, du accepterer når du går event-driven.