Ce este arhitectura bazată pe evenimente în microservicii?

Question

Accepted Answer

Într-o **arhitectură bazată pe evenimente**, serviciile comunică prin **producerea și consumarea evenimentelor** printr-un broker (Kafka, RabbitMQ, etc.). Un serviciu anunță că ceva s-a întâmplat; serviciile interesate reacționează — producătorul nu le cunoaște sau nu le așteaptă.

## Cum funcționează

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

## Exemplu de încărcătură de eveniment

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

## Beneficii

- **Cuplaj vag** — adăugați un nou consumator fără să atingeți producătorul.
- **Reziliență** — brokerul stochează în buffer evenimentele în caz de întreruperi.
- **Scalabilitate** — consumatorii se scalează în mod independent.

## Capcane

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

## De ce este important

Proiectarea bazată pe evenimente este ceea ce vă permite să adăugați capacități (analiză, verificare fraudă, notificări) pur și simplu prin abonare, fără modificări aduse producătorilor existenți.

Acea extensibilitate și reziliență vin cu prețul consistenței eventual și depanării mai dificile — compromisul central pe care îl acceptați atunci când mergeți pe cale event-driven.