Saga e Process Manager: coordinare workflow distribuiti senza transazione globale
Saga e Process Manager coordinano processi che attraversano più servizi quando una singola transazione ACID non può coprire l'intero workflow.
Quando nasce il problema
Un processo può attraversare più bounded context: accettazione, assegnazione letto, preparazione cartella, ordini iniziali, documentazione. Non è opportuno racchiudere tutto in una transazione distribuita che blocca database e servizi. Ogni contesto deve poter confermare localmente la propria operazione.
Saga
Una Saga è una sequenza di transazioni locali collegate. Se un passo successivo fallisce, si applicano azioni compensative dove il dominio lo consente. Una compensazione non è un rollback tecnico: è una nuova azione di business che porta il sistema in uno stato valido.
Process Manager
Il Process Manager è un componente con stato che conosce l'avanzamento del processo e decide il prossimo comando in base agli eventi ricevuti. È utile quando il workflow ha timeout, ramificazioni, retry e più partecipanti.
Choreography e orchestration
Choreography: ogni servizio reagisce agli eventi e produce nuovi eventi. È semplice per flussi lineari ma può diventare difficile da comprendere quando aumentano i passaggi.
Orchestration: un Process Manager invia comandi ai partecipanti e registra lo stato. Rende il flusso più visibile ma introduce un coordinatore da progettare come componente di processo, non come nuovo monolite di business logic.
Compensazioni
Non tutto è compensabile. Un documento firmato, una comunicazione già inviata o un evento clinico registrato possono richiedere rettifica o annullamento tracciato, non cancellazione. Il modello della Saga deve rispettare auditabilità e semantica del dominio.
Quando NON usare una Saga
Una singola transazione locale nel bounded context è sufficiente.
Il flusso è una semplice fan-out di notifiche senza stato di processo.
Il problema è solo affidabilità del publish: basta Outbox.
Si sta usando la Saga per nascondere bounded context disegnati male e che dovrebbero condividere la stessa transazione.
Osservabilità
Ogni istanza di processo dovrebbe avere processId/correlationId, stato corrente, step completati, ultimo errore, retry count, deadline e audit trail. Senza questa visibilità, i workflow distribuiti diventano più difficili da operare del legacy che volevano sostituire.