Saga - OLife'S · OLife'S

Saga

Architectural Patterns

Meaning

The Saga pattern manages data consistency across microservices by decomposing a distributed transaction into a sequence of local transactions, each paired with a compensating action that semantically reverses it. It addresses the impossibility of traditional ACID transactions spanning multiple services without distributed locks. Developers reach for it when a business operation must touch several services and atomicity cannot be guaranteed by a single database.

Primary Function

Distributed transaction coordination

Communicative Purpose

Ensures eventual consistency across microservices without requiring distributed locks or two-phase commit protocols.

Pattern

initiate saga → execute local transaction N → on success trigger N+1 → on failure invoke compensating transaction for completed steps → reach final consistent state

Função primária

Distributed transaction coordination

Propósito comunicativo

Ensures eventual consistency across microservices without requiring distributed locks or two-phase commit protocols.

Situações de gatilho

Microservices: order fulfillment spanning inventory, payment, and shipping services; Distributed systems: cross-service workflows where each step must succeed or be compensated; Event-driven architecture: long-running business processes that span multiple bounded contexts

Contextos

Microservices architectures, event-driven systems, CQRS plus Event Sourcing stacks, e-commerce order pipelines, distributed transaction management

Padrão

initiate saga → execute local transaction N → on success trigger N+1 → on failure invoke compensating transaction for completed steps → reach final consistent state

Colocados típicos

compensating transaction
choreography
orchestration
saga coordinator
event bus
idempotent handler
eventual consistency

Substituições comuns

Two-phase commit (2PC) — strong consistency but couples services and blocks
Distributed transaction coordinator (XA) — heavyweight
poor scalability across services
Event sourcing alone — captures changes but does not define rollback semantics

Erros comuns

Assuming saga provides ACID guarantees — it offers eventual consistency, not isolation, so intermediate states are visible; Forgetting idempotency on compensating actions — retries can double-refund or double-cancel; Treating saga as a single atomic unit — partial failures are expected and must be handled explicitly; Skipping observability for saga state — debugging stuck sagas without distributed tracing is nearly impossible; Coupling saga steps via synchronous calls — defeats the autonomy microservices promise

Similar / contraste

Two-phase commit — synchronous, blocking, strong consistency; Workflow engine (Temporal, Camunda) — saga is a pattern, these are concrete implementations; Process manager — orchestrator variant of saga; Unit of Work — single-process transactional boundary, not cross-service

Interferências

Coming from monolithic RDBMS apps: may assume a single ACID transaction covers everything — microservices require explicit compensation logic; Coming from Java EE: may reach for JTA/XA distributed transactions — these do not scale across service boundaries and create tight coupling

Família do chunk

compensating transaction
two-phase commit
event sourcing
CQRS
process manager
outbox pattern

Nuance

When NOT to use: single-database transactions or operations that do not cross service boundaries — overhead is unjustified. Performance: each step adds latency and the compensating path can be expensive; sagas are not free. Boundary conditions: compensating actions must be idempotent and semantically reversible — not always possible (e.g., sending an email cannot be unsent, only apologized for).

Efeito pragmático

Enables loosely coupled services to collaborate on multi-step business processes while preserving autonomy and avoiding distributed locks that kill scalability.

Dica de memória

Saga: like a chain of dominoes where each piece knows how to un-fall itself — every forward step has a backward twin ready to undo it if the chain breaks.

Upgrade path

Orchestration vs choreography trade-offs; idempotent saga handlers; saga observability with distributed tracing; outbox pattern for reliable event publishing

Frequência: MediumFormulaicidade: FlexiblePrioridade de aquisição: Active recallPrioridade de output: BothTag de espaçamento: Long-term

Examples

class OrderSaga: def execute(self, order): try: self.reserve_inventory(order) self.charge_payment(order) self.schedule_shipping(order) except SagaStepFailed as error: self.compensate(order, error.failed_step) def compensate(self, order, failed_step): if failed_step == "shipping": self.refund_payment(order) if failed_step in ("payment", "shipping"): self.release_inventory(order)

# Choreography-based saga: each service reacts to events and publishes its own on OrderPlaced: inventory_service.reserve(order) publish InventoryReserved(order) on InventoryReserved: payment_service.charge(order) publish PaymentCharged(order) on PaymentFailed: inventory_service.release(order) publish OrderCancelled(order)

@workflow.defn class OrderWorkflow: @workflow.run async def run(self, order: Order) -> str: reserve = await workflow.execute_activity( reserve_inventory, order, start_to_close_timeout=timedelta(seconds=10) ) if not reserve.success: return "inventory_unavailable" payment = await workflow.execute_activity( charge_payment, order, start_to_close_timeout=timedelta(seconds=30) ) if not payment.success: await workflow.execute_activity(release_inventory, order) return "payment_failed" await workflow.execute_activity(schedule_shipping, order) return "order_completed"