Het saga-patroon is een manier om een bedrijfsproces te coördineren dat over meerdere losse services loopt, waar geen enkele database kan garanderen dat het geheel als één geheel slaagt of faalt. In plaats daarvan wordt het proces opgeknipt in stappen, en elke stap heeft een bijbehorende ongedaan-maak-actie voor het geval een latere stap fout gaat.
Stel je het boeken van een vakantie voor: vlucht, hotel en auto, elk bij een ander bedrijf. Je kunt die drie niet in één ondeelbare actie reserveren. Dus boek je de vlucht, dan het hotel, dan de auto, en als de auto afvalt, annuleer je het hotel en de vlucht om weer in een schone staat te komen. Die annulering is de ‘compenserende actie’, en het aan elkaar rijgen van die stappen en ongedaan-maak-acties is de saga. Het is een veelgebruikt ontwerppatroon in systemen van microservices, vaak aangedreven door berichten op een queue.
Er zijn twee manieren om er één te draaien. Bij choreografie reageert elke service op events en zet hij zelf de volgende stap aan. Bij orkestratie roept een centrale coördinator elke service om de beurt aan en regelt hij de ongedaan-maak-acties. Choreografie is lichter; orkestratie is makkelijker te volgen als de flow lang wordt.
Eén praktische kanttekening: doordat stappen en retries zich kunnen herhalen, moet elke actie veilig twee keer uit te voeren zijn, en daar komt idempotentie bij kijken. De afweging is echte complexiteit. Een saga verdient zich pas terug als een proces echt over services loopt; binnen één service en één database is een gewone transactie simpeler en veiliger.
Bij TopDevs grijpen we naar het saga-patroon alleen als een proces echt over servicegrenzen heen gaat, zodat je betrouwbaarheid wint zonder complexiteit op te stapelen die je niet nodig hebt.
