Cos'è l'architettura event-driven nei microservizi?

Question

Accepted Answer

In un'**architettura event-driven**, i servizi comunicano **producendo e consumando eventi** tramite un broker (Kafka, RabbitMQ, ecc.). Un servizio annuncia che qualcosa è accaduto; i servizi interessati reagiscono — il producer non conosce o aspetta loro.

## Come funziona

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

## Esempio di payload di evento

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

## Vantaggi

- **Loose coupling** — aggiungere un nuovo consumer senza modificare il producer.
- **Resilienza** — il broker bufferizza gli eventi durante le interruzioni.
- **Scalabilità** — i consumer scalano indipendentemente.

## Insidie

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

## Perché è importante

Il design event-driven è ciò che ti consente di aggiungere funzionalità (analytics, fraud checks, notifiche) semplicemente sottoscrivendo, senza alcuna modifica ai producer esistenti.

Questa estensibilità e resilienza hanno il prezzo della eventual consistency e del debugging più difficile — il compromesso centrale che accetti quando adotti l'event-driven.