Het Saga Pattern gebruik ik binnen gedistribueerde systemen om processen te beheren die over meerdere services heen lopen. Iedere service voert zijn eigen transactie uit en communiceert het resultaat naar de volgende stap. Wanneer ergens iets misgaat, wordt dat opgelost met een compenserende actie in plaats van één grote rollback.
Voor mij is Saga vooral relevant wanneer je bewust kiest voor Eventual Consistency. Je accepteert dat het systeem tijdelijk niet overal dezelfde status heeft, maar zorgt er wel voor dat het proces uiteindelijk naar een consistente toestand beweegt.
Belangrijk om te weten
Een Saga lost niet automatisch alle problemen rondom gedistribueerde transacties op. Je verplaatst een deel van de complexiteit juist naar je applicatielogica.
Daarom let ik vooral op:
Idempotency: hetzelfde event meerdere keren verwerken mag geen ongewenste bijwerkingen veroorzaken.
Compensating actions: iedere belangrijke stap moet een duidelijk herstelpad hebben.
Observability: je moet kunnen zien waar een proces zich bevindt en waarom iets is mislukt.
Event ownership: het moet duidelijk zijn welke service verantwoordelijk is voor welke statuswijziging.
Simpliciteit: niet ieder proces heeft een Saga nodig. Als Immediate Consistency eenvoudiger en logisch genoeg is, heeft dat mijn voorkeur.
Hoe ik het gebruik
Ik gebruik het Saga Pattern voornamelijk binnen event-driven microservice architecturen waarin één bedrijfsproces meerdere services raakt.
Een typische flow kan bijvoorbeeld bestaan uit:
Service A → Event → Service B → Event → Service C
Iedere service verwerkt zijn eigen verantwoordelijkheid zelfstandig. Wanneer Service C faalt, hoeft Service A niet technisch teruggedraaid te worden via een gedeelde database-transactie. In plaats daarvan wordt vanuit het proces bepaald welke compenserende actie nodig is.
Dat vraagt om meer discipline in het ontwerp, maar geeft services tegelijkertijd veel meer autonomie.
Waar ik het heb gebruikt
Ik heb het Saga Pattern onder andere toegepast bij het ontwerpen van microservice prototypes waarin ik Immediate Consistency en Eventual Consistency met elkaar heb vergeleken. Hierbij gebruikte ik Java 17, Quarkus, Kafka, MongoDB en Docker. Binnen het Eventual Consistency scenario werd Kafka gebruikt als eventbus en Saga als strategie om transacties over meerdere services heen te beheren.
Ook heb ik het patroon toegepast binnen een SaaS platform bestaande uit vijf microservices die via Kafka met elkaar communiceerden. Omdat meerdere processen verspreid over services liepen, heb ik daarnaast een aparte Go service gebouwd om deze processen inzichtelijk te maken en hun status bij te houden.
Mijn ervaring met Saga
Wat ik vooral uit het gebruik van Saga heb meegenomen, is dat Eventual Consistency technisch niet het moeilijkste onderdeel is. De echte uitdaging zit in het ontwerpen van het proces eromheen.
Je moet vooraf nadenken over vragen zoals: wat gebeurt er bij een gedeeltelijke fout, kan een actie opnieuw uitgevoerd worden, wie is eigenaar van het proces en hoe weet je uiteindelijk dat een volledige flow succesvol is afgerond?
Daarom zie ik Saga niet als een los technisch pattern. Het is onderdeel van hoe je een gedistribueerd bedrijfsproces ontwerpt.
Een goede Saga voelt uiteindelijk voorspelbaar. Niet omdat er niets fout kan gaan, maar omdat vooraf duidelijk is wat het systeem doet wanneer dat wel gebeurt.
Veelgestelde vragen die ik krijg over Saga Pattern
Wanneer gebruik je Saga?
Wanneer één bedrijfsproces meerdere onafhankelijke services raakt en je geen gedeelde database-transactie wilt of kunt gebruiken. Vooral binnen Eventual Consistency is het een sterk patroon.
Choreography of orchestration?
Ik kijk naar de complexiteit van het proces. Voor eenvoudige flows kan choreography prima werken. Zodra veel stappen, uitzonderingen en compensaties ontstaan, geeft orchestration vaak meer overzicht.
Is Saga altijd nodig bij microservices?
Nee. Een Saga introduceren omdat je microservices gebruikt, maakt een systeem onnodig complex. Het bedrijfsproces moet de aanleiding zijn.
Wat vind je het lastigste aan Saga?
Niet het versturen van events, maar foutafhandeling. Vooral retries, dubbele berichten, compensaties en inzicht krijgen in langlopende processen vragen om een goed ontwerp.
Saga of Immediate Consistency?
Dat is geen keuze die ik vanuit techniek alleen maak. Als Immediate Consistency eenvoudiger is en past bij het bedrijfsproces, gebruik ik dat. Wanneer services onafhankelijk moeten kunnen werken en tijdelijke inconsistentie acceptabel is, wordt Saga interessanter.