Multi-Step Distributed Workflows (Saga & Outbox Pattern)

In a microservices architecture, business workflows span multiple independent services (e.g. Order Service, Payment Service, Inventory Service). Because distributed Two-Phase Commit (2PC) does not scale well over networks, modern systems use the Saga Pattern.

1. The Saga Pattern

A Saga is a sequence of local transactions where each step updates a local database and emits a message. If a step fails, the Saga executes Compensating Transactions to undo prior steps:

Step 1: Reserve Inventory (Success)
Step 2: Debit Customer Card (Failed - Insufficient Funds!)
Compensation Step 1: Release Reserved Inventory

Orchestration vs. Choreography

• Choreography (Event-Driven): Services listen to Kafka events and publish completion events. Simple for short workflows, but difficult to monitor and debug as topologies grow.
• Orchestration (Centralized Coordinator): A dedicated workflow engine (Temporal, AWS Step Functions) centrally commands each participant what step to execute next and handles timeouts.

2. The Transactional Outbox Pattern

How do you guarantee that a database update and a Kafka message emission both succeed without dual-write failures?

1. Write the business data AND the outbound event into an outbox table within the same local ACID database transaction.
2. A background Debezium (Change Data Capture) or Polling process reads the outbox table and streams the events to Kafka with at-least-once delivery.

Key Architecture Trade-Offs & Decision Matrix