Hva er event-driven architecture i microservices?

Question

Accepted Answer

I en **event-driven architecture** kommuniserer tjenester ved å **produsere og konsumere events** gjennom en megler (Kafka, RabbitMQ, osv.). En tjeneste kunngjør at noe skjedde; interesserte tjenester reagerer — produsenten vet ikke eller venter ikke på dem.

## Hvordan det fungerer

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

## Fordeler

- **Løs kobling** — legg til en ny consumer uten å røre produsenten.
- **Motstandskraft** — megleren buffrer events under nedetid.
- **Skalérbarhet** — consumere skaleres uavhengig.

## Fallgruver

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

Event-driven design er det som lar deg legge til evner (analytics, svindelkontroll, meldinger) ved ganske enkelt å abonnere, uten endringer til eksisterende produsenter.

Den utvidelsen og motstandskraften kommer på bekostning av til slutt konsistens og vanskeligere feilsøking — det sentrale kompromisset du aksepterer når du går event-driven.