Distributed Data
Why one transaction cannot span services: sagas, compensation, CQRS and event sourcing — and why most apps need none of them.
Once an order, a payment and an inventory reservation live in three services with three databases, no single `COMMIT` covers them; two-phase commit can make it look like one but is avoided for good reasons, so production systems use sagas, compensation and the outbox pattern instead.
A saga is a business transaction spread over several services as a sequence of local transactions, each with a compensating action; the flow either completes or is unwound step by step, passing through pending states the user can see, and driven either by an orchestrator or by a chain of events.
Command Query Responsibility Segregation splits the model that accepts writes from the model that serves reads, so each can have its own shape, storage and scaling — at the price of a projection that lags, a rebuild story, and two models to keep in agreement; most applications should stop at CQRS-lite.
Instead of storing `balance = 100`, store `AccountCreated +100`, `PaymentMade −20`, `RefundReceived +20` and derive the balance by replaying the log; you gain a complete audit trail, time travel and rebuildable projections, and pay with snapshots, event versioning, GDPR pain and a model most applications do not need.