Saga pattern

Wat is het saga pattern?

Het saga pattern is een manier om een businessproces over meerdere systemen betrouwbaar te sturen zonder één grote database-transactie. Je splitst het proces op in lokale transacties. Als een stap later faalt, voer je compenserende acties uit voor de stappen die al gelukt waren.

Neem een webshoporder. Betaling reserveren, voorraad vastleggen en verzending aanmaken zitten vaak in verschillende systemen. Je kan die systemen niet altijd in één ACID-transactie stoppen. Een saga maakt er een reeks afspraken van.

Het doel is niet alles doen alsof het één database is. Het doel is elk systeem lokaal correct laten handelen en fouten netjes terugdraaien waar dat kan.

Hoe werkt een saga?

Een saga bestaat uit stappen en compensaties. Elke stap doet een lokale transactie en start daarna de volgende stap. Faalt stap drie, dan voer je compensaties uit voor stap twee en één.

1. Maak de order aan.

2. Reserveer betaling.

3. Reserveer voorraad.

4. Maak verzending aan.

Als voorraad reserveren faalt, annuleer je de betalingsreservering en zet je de order op geannuleerd. Dat is geen perfecte terugspoeling van de tijd, maar een businesscorrectie.

Orchestratie versus choreografie

Bij orchestration is er een centrale coordinator die beslist welke stap volgt. Die coordinator weet waar de saga staat en welke compensatie nodig is bij een fout.

Bij choreography reageert elke service op events. De order service publiceert OrderCreated, de payment service reageert met PaymentReserved, en zo gaat het proces verder. Er is minder centrale sturing, maar het kan moeilijker zijn om het volledige proces te overzien.

In KMO-context is orchestration vaak makkelijker te beheren, omdat je één plek hebt om status, retries en fouten te volgen.

Wanneer gebruik je het saga pattern?

• Bij processen over meerdere systemen. Denk aan betaling, voorraad, verzending en facturatie.

• Wanneer stappen tijd vragen. Een externe API kan later antwoorden of tijdelijk falen.

• Wanneer een klassieke distributed transaction niet past. Veel cloudservices en SaaS-systemen ondersteunen die niet.

• Wanneer compensatie businesslogica is. Een reservatie annuleren is iets anders dan een SQL-rollback.

Waar moet je op letten bij het saga pattern

• Compensatie is geen magie. Een verzonden pakket kan je niet on-verzenden. Je kan wel een retourproces starten.

• Elke stap moet idempotent zijn. Retries mogen niet dubbel reserveren of dubbel factureren.

• Monitoring is verplicht. Een saga kan halverwege blijven hangen. Je hebt zicht nodig op status en fouten.

• Data is tijdelijk inconsistent. Tussen stappen kunnen systemen even verschillende waarheden tonen. Dat moet het proces aankunnen.

FAQ over het saga pattern

1. Is een saga hetzelfde als een workflow?
Een saga is een soort workflow met nadruk op lokale transacties en compensaties. Niet elke workflow is een saga.

2. Heb ik microservices nodig voor saga's?
Nee. Het patroon is ook nuttig bij integraties tussen SaaS-systemen, ERP, CRM en externe API's.

3. Lost een saga alle inconsistentie op?
Nee. Ze beheerst inconsistentie door status, compensatie en retries expliciet te maken.