Una saga gestisce una transazione di business che si estende su più servizi come una sequenza di transazioni locali. Se un passo fallisce, la saga esegue transazioni compensative per annullare i passi precedenti — non c'è rollback distribuito.
Il two-phase commit tra servizi è lento, blocca risorse e accoppia la disponibilità. Le saga garantiscono coerenza eventuale senza lock distribuiti.
I servizi reagiscono agli eventi reciproci; nessun coordinatore centrale.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
Un orchestratore dice a ogni servizio cosa fare e reagisce ai risultati.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspetto | Coreografia | Orchestrazione |
|---|---|---|
| Coordinamento | Distribuito (eventi) | Centralizzato |
| Accoppiamento | Più lasco | L'orchestratore conosce il flusso |
| Visibilità | Difficile da seguire | Facile da tracciare |
| Migliore per | Semplice, pochi passi | Complesso, molti passi |
Le compensazioni devono essere idempotenti e gestire il caso in cui il passo originale abbia avuto successo parziale. Progettale con attenzione.
Le saga sono il modo in cui mantieni la coerenza dei dati tra i servizi senza il costo e l'accoppiamento delle transazioni distribuite.
Scegliere coreografia vs orchestrazione comporta un compromesso tra semplicità e visibilità: gli eventi si scalano debolmente ma diventano complicati, mentre un orchestratore centralizza la logica complessa al costo di un componente in più da eseguire.