Co to jest architektura oparta na zdarzeniach w mikroserwisach?

Question

Accepted Answer

W **architekturze opartej na zdarzeniach** usługi komunikują się, **produkując i konsumując zdarzenia** za pośrednictwem brokera (Kafka, RabbitMQ, itp.). Usługa ogłasza, że coś się stało; zainteresowane usługi reagują — producent ich nie zna ani na nich nie czeka.

## Jak to działa

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

## Przykład ładunku zdarzenia

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

## Korzyści

- **Luźne powiązanie** — dodaj nowego konsumenta bez dotykania producenta.
- **Odporność** — broker buforuje zdarzenia podczas awarii.
- **Skalowalność** — konsumenci skalują się niezależnie.

## Pułapki

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

## Dlaczego to ważne

Projekt oparty na zdarzeniach to coś, co umożliwia dodawanie możliwości (analityka, sprawdzanie oszustw, powiadomienia) poprzez prosty subskrypcję, bez zmian w istniejących producentach.

Ta rozszerzalność i odporność mają cenę ostatecznej spójności i trudniejszego debugowania — centralny kompromis, który akceptujesz, przechodząc na model oparty na zdarzeniach.