Implementeer een gecentraliseerde Saga Orchestrator met behulp van Temporal of Netflix Conductor die duurzame workflowstatus in PostgreSQL onderhoudt met gRPC-communicatie naar domeindiensten. Het patroon vereist idempotentiekeys die zijn opgeslagen in een Redis Cluster met TTL-vensters die overeenkomen met zakelijke beperkingen, terwijl Apache Kafka dient als de evenementen backbone voor audit trails en compensatietriggers. Elke saga-stap moet compenserende transacties bevatten die omgekeerde bewerkingen uitvoeren met behulp van het Saga State Machine patroon, met expliciete staten (PENDING, SUCCEEDED, COMPENSATING, COMPENSATED) die worden bijgehouden in etcd of ZooKeeper voor clustercoördinatie.
┌─────────────────┐ ┌──────────────┐ ┌─────────────────┐
│ API Gateway │────▶│ Temporal │────▶│ Voorraad │
└─────────────────┘ │ Orchestrator│ │ Dienst │
└──────────────┘ └─────────────────┘
│ │
▼ ▼
┌──────────────┐ ┌─────────────────┐
│ PostgreSQL │ │ PostgreSQL │
│ Status Opslag│ │ (Compensatie │
└──────────────┘ │ Logica) │
└─────────────────┘
Een wereldwijd hotelboekingsplatform had moeite met cascaderende fouten bij het coördineren van kamerreserveringen, betalingsverwerking en loyaliteitspuntenupdates over drie verschillende Kubernetes-clusters in verschillende regio's. Hun legacy-implementatie gebruikte Two-Phase Commit (2PC) over REST-API's, wat leidde tot wijdverspreide deadlocks tijdens piekverkeer wanneer de betalingsgateway latentiepieken van meer dan 10 seconden ondervond.
Het team evalueerde Choreography-Based Saga met behulp van Amazon EventBridge, waarbij elke dienst domeinevenementen publiceerde naar een gedeelde bus. Deze aanpak elimineerde het enkele punt van falen en verlaagde de infrastructuurkosten met 40%. Echter, het introduceerde ernstige observabiliteitsuitdagingen, aangezien het bepalen of een complexe multi-kamer boeking was geslaagd vereiste dat logs over zeventien microservices werden geraadpleegd. De impliciete afhankelijkheden maakten het onmogelijk om consistente time-outbeleid af te dwingen, en het debuggen van productieproblemen werd een forensische oefening die zich over meerdere AWS CloudWatch-dashboards uitstrekte.
Ze prototypeerden een Orchestrated Saga met behulp van een aangepaste Node.js-coördinator die werd ingezet op AWS ECS. Dit centraliseerde de bedrijfslogica en vereenvoudigde monitoring via een uniforme Grafana-dashboard. Helaas werd de initiële implementatie alleen in het geheugen opgeslagen, wat resulteerde in catastrofale gegevensverlies toen de coördinator opnieuw opstartte tijdens implementaties. Dertig transacties kwamen in onbekende staten terecht, waardoor handmatige database-reconcilatie drie dagen in beslag nam en leidde tot aanzienlijke omzetverlies door dubbel-gefactureerde klanten.
De gekozen oplossing implementeerde Temporal als de workflow-engine met Cassandra persistentie, wat de status duurzaamheid gedurende pod-herstarts en AZ-fouten waarborgde. De architectuur gebruikte Protobuf-schema's voor type-veilige communicatie tussen de orchestrator en domeindiensten, waarbij Redis Sentinel idempotentiekeys beheerde. Wanneer de betalingsdienst een regionale storing in us-east-1 ondervond, activeerde de saga automatisch compensatieworkflows die kamerbeperkingen binnen 200ms vrijgaven en loyaliteitspunten atomair introkken.
Het systeem verwerkt nu dagelijks 50.000 complexe boekingen met 99,99% consistentie garanties en geen handmatige interventies tijdens netwerkpartities. De gemiddelde tijd om storingen te detecteren (MTTD) daalde van 45 minuten naar 8 seconden, terwijl de compensatietijd onder de 500ms blijft bij p99.
Hoe ga je om met partiële compensatiefouten wanneer een compenserende transactie zelf faalt, wat het systeem in een inconsistente toestand kan achterlaten?
Implementeer een Compensatie Audit Log met behulp van Event Sourcing waarbij elke gepogende compensatie wordt geregistreerd als een onveranderlijk evenement in Apache Kafka met oneindige retentie. Het systeem moet onderscheiden tussen tijdelijke infrastructuurproblemen die een automatische herhaling vereisen met exponentiële backoff en zakelijke logica-overtredingen die menselijke interventie vereisen. Voor tijdelijke problemen, gebruik Dead Letter Queues (DLQ) in RabbitMQ of Amazon SQS die compensaties opnieuw verwerken na serviceherstel met jitter om te voorkomen dat de woedende kudde optreedt. Voor overtredingen van zakelijke regels, zoals het proberen te restitueren van een al verrekende transactie, komt de saga in een 'COMPENSATION_FAILED' toestand die PagerDuty-waarschuwingen activeert terwijl het CQRS-patroon wordt toegepast om de aggregate root via het commandmodel te bevriezen. Ontwerp compensaties altijd zo dat ze idempotent zijn met behulp van unieke databasebeperkingen of Redis SETNX-bewerkingen, zodat herhalingen geen bijeffecten creëren.
Wat is het fundamentele architecturale verschil tussen choreografie en orkestratie met betrekking tot temporele koppeling en het vermogen om 'wat is de huidige transactiestatus' vragen te beantwoorden?
Choreografie volgt het Reactive Manifesto, waardoor temporele ontkoppeling ontstaat waarbij diensten reageren op evenementen zonder kennis van upstream of downstream deelnemers, maar het biedt wel de mogelijkheid om de saga-status te achterhalen zonder complexe Distributed Tracing met Jaeger of AWS X-Ray te bouwen. De status wordt emergent uit evenementenlogs, waardoor CQRS leesmodelprojecties nodig zijn om 'is de boeking compleet' vragen te beantwoorden. Orkestratie introduceert expliciete temporele koppeling tussen de coördinator en werkers, aangezien de orchestrator beschikbaar moet zijn om volgende stappen te triggeren, maar biedt een enkele bron van waarheid in zijn statusopslag (PostgreSQL/CockroachDB). Dit maakt onmiddellijke statusvragen mogelijk, maar creëert een netwerkafhankelijkheid. De cruciale inzicht is dat choreografie vereist dat state machines in elke consument worden geïmplementeerd, terwijl orkestratie deze complexiteit centraliseert; voor systemen die sterke auditbaarheid en compliance vereisen (PCI-DSS), heeft orkestratie de voorkeur ondanks de kosten van koppeling.
Hoe voorkom je dubbele saga-executie bij het gebruik van tenminste-eenmaal bezorgingssemantic in berichtenbrokers tijdens Kafka-consument-herverdelingen of Kubernetes pod-herstarts?
Implementeer Idempotent Consumer-patronen met behulp van Redis of Memcached om verwerkte bericht-ID's op te slaan met deduplicatievensters die overeenkomen met je Recovery Point Objective (RPO), meestal 24-48 uur voor financiële systemen. Wanneer een saga orchestrator een opdracht ontvangt, genereer een deterministische idempotentiekey door de correlatie-ID met een zakelijke sleutel (klant-ID + boekingsreferentie) te hashen voordat je eventuele bijeffecten uitvoert. Elke domeindienst moet deze sleutel valideren tegen zijn Idempotency Store, geïmplementeerd als een PostgreSQL-tabel met unieke beperkingen op samengestelde sleutels of Bloom Filters in Redis voor geheugenefficiënte negatieve opzoekingen. Voor langlopende saga's, gebruik Saga State Machines met optimistische vergrendeling via etcd versievectoren om exact-eens verwerkingssemantiek over gedistribueerde knooppunten te hanteren. Dit voorkomt dubbele boeking scenario's wanneer consumentengroepen worden herverdeeld tijdens implementaties of tijdens netwerkpartities die Kubernetes livenessProbe herstarts activeren.