Vad är event-driven arkitektur i mikrotjänster?

Question

Accepted Answer

I en **event-driven arkitektur** kommunicerar tjänster genom att **producera och konsumera händelser** via en broker (Kafka, RabbitMQ, osv.). En tjänst presenterar att något hände; intresserade tjänster reagerar — producenten vet inte eller väntar inte på dem.

## Hur det fungerar

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

## Exempel 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 }
}
```

## Fördelar

- **Löst kopplad** — lägg till en ny konsument utan att röra producenten.
- **Motståndskraft** — brokern buffrar händelser under avbrott.
- **Skalbarhet** — konsumenter skalas oberoende.

## Fallgropar

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

## Varför det är viktigt

Event-driven design är det som låter dig lägga till funktioner (analys, bedrägeriöversättningar, aviseringar) genom att enkelt prenumerera, utan ändringar i befintliga producenter.

Denna utökningsbarhet och motståndskraft kommer till priset av eventuell konsekvens och svårare felsökning — den centrala kompromissen du accepterar när du går event-driven.