Mi az event-driven architecture a mikroszolgáltatásokban?

Question

Accepted Answer

Az **event-driven architecture**-ban a szolgáltatások **eseményeket termelnek és fogyasztanak** egy broker-on (Kafka, RabbitMQ, stb.) keresztül. Egy szolgáltatás bejelenti, hogy valami történt; az érdekelt szolgáltatások reagálnak — a termelő nem tudja vagy nem várja meg őket.

## Hogyan működik

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

## Event payload példa

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

## Előnyök

- **Laza csatolás** — új consumer hozzáadása a producer módosítása nélkül.
- **Rugalmasság** — a broker puffereli az eseményeket az üzemzavarok alatt.
- **Skalázhatóság** — a fogyasztók függetlenül skálázódnak.

## Buktatók

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

## Miért számít

Az event-driven design az, ami lehetővé teszi, hogy képességeket (analitika, csalásdetektálás, értesítések) egyszerűen feliratkozva adjunk hozzá, a meglévő termelőkön végzett nulla módosítással.

Ez a kiterjeszthetőség és rugalmasság végső konzisztenciájú és nehezebb hibakeresésből származó árát jelenti — ez a központi kompromisszum, amelyet elfogad az event-driven megközelítés választásakor.