Saga Pattern — Distributed Transactions in Microservices

Distributed transactions are one of the hardest problems in microservices because @Transactional cannot span multiple databases.

• Two-phase commit technically works but holds locks across all participants until every database votes — unacceptable at scale.
• The Saga pattern replaces one atomic transaction with a sequence of local transactions, each within a single service's database.

Compensating transactions — the key insight:

• Compensation is not a database rollback — when payment succeeded but inventory is out of stock, you issue a refund, which is a new forward operation creating a credit record
• Compensating transactions must be idempotent because at-least-once delivery can trigger them multiple times — a compensation command arriving twice must produce the same outcome as once
• Every step in a saga must have a defined compensation that can be executed independently

Choreography vs orchestration:

• Choreography has no central coordinator — each service reacts to others' events; clean for 2–3 step flows but becomes unmanageable past 5 services where the interaction graph is invisible
• Orchestration uses a dedicated state machine that sends commands, tracks which steps completed, and drives compensation when something fails — the workflow is in one class, easy to debug and test, but the coordinator needs to be highly available and persistent

Operational visibility:

• Monitor saga duration and alert when one stays in an intermediate state longer than your SLA (1–5 minutes for order flows) — the most common cause is a consumer crash with an unprocessed message in a dead-letter queue

I recommend orchestration for business-critical sagas with conditional logic or many participants, and choreography only for simple linear flows with 2–3 services.