Co je architektura řízená událostmi v mikroslužbách?

Question

Accepted Answer

V **architektuře řízené událostmi** si služby vyměňují informace **produkcí a spotřebou událostí** prostřednictvím zprostředkovatele (Kafka, RabbitMQ atd.). Služba oznámí, že se něco stalo; zainteresované služby na to reagují — producent o nich neví ani na ně nečeká.

## Jak to funguje

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

## Příklad obsahu události

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

## Výhody

- **Volná vazba** — přidejte nového spotřebitele bez doteku producenta.
- **Odolnost** — zprostředkovatel ukládá události během výpadků do vyrovnávací paměti.
- **Škálovatelnost** — spotřebitelé se škálují nezávisle.

## Úskalí

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

## Proč je to důležité

Na architektuře řízené událostmi se zakládá to, že můžete přidat schopnosti (analýzu, kontrolu podvodů, oznámení) pouhým přihlášením bez jakýchkoli změn stávajících producentů.

Tato rozšiřitelnost a odolnost přichází za cenu konečné konzistence a obtížnějšího ladění — to je ústřední kompromis, který přijímáte při přechodu na architekturu řizenou událostmi.