Što je event-driven arhitektura u mikroservisima?

Question

Accepted Answer

U **event-driven arhitekturi**, servisi komuniciraju **proizvodnjom i konzumacijom događaja** preko broker-a (Kafka, RabbitMQ, itd.). Servis objavljuje da se nešto dogodilo; zainteresirani servisi reagiraju — producent ne zna niti čeka njihov odgovor.

## Kako funkcionira

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

## Primjer event payload-a

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

## Prednosti

- **Labava vezanost** — dodajte novog konzumenta bez dodira na producenta.
- **Otpornost** — broker pufferira događaje tijekom ispada.
- **Skalabilnost** — konzumenti se skaliraju nezavisno.

## Nedostaci

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

## Zašto je važno

Event-driven dizajn je ono što vam omogućuje dodavanje mogućnosti (analitika, provjera prevara, obavijesti) jednostavnom pretplatom, bez bilo kakvih promjena postojećim producerima.

Ta proširivost i otpornost dolaze po cijeni eventualne konzistencije i težeg debugiranja — centralni kompromis koji prihvaćate pri prijelazu na event-driven pristup.