How do you keep consistency without multi-document transactions?

WHAT THIS TESTS This probes how you achieve cross-document or cross-service consistency when you cannot rely on a single ACID transaction, a core challenge in microservices and distributed data.

A GOOD ANSWER COVERS The Saga pattern models a business operation as a sequence of local transactions, each committed in its own service or document. After each successful step, the next is triggered. If a step fails, the Saga runs compensating transactions in reverse to semantically undo the already-committed steps, since you cannot roll them back atomically. There are two coordination styles: choreography, where each service emits events that the next consumes, simple but harder to trace; and orchestration, where a central coordinator issues commands and tracks state, clearer for complex flows. Compare this to an application-level two-phase commit, where a coordinator asks all participants to prepare, then commit or abort. Two-phase commit gives stronger atomicity but blocks resources and stalls if the coordinator fails, which is why Sagas are usually preferred for long-lived distributed work. Crucially, Sagas provide atomicity through compensation but not isolation, so intermediate states are visible.

COMMON WRONG ANSWERS Describing a Saga as a drop-in replacement that gives full ACID, ignoring the lack of isolation and the possibility of seeing partial results. Forgetting compensating actions entirely. Overlooking idempotency and retries, which are essential because messages can be delivered more than once. Recommending two-phase commit everywhere despite its blocking and coordinator-failure problems.

LIKELY FOLLOW-UPS How do you design a compensating transaction that cannot truly undo a side effect like a sent email? How do you guarantee idempotency? How do you handle the coordinator crashing mid-Saga? When is two-phase commit still appropriate?

ONE CONCRETE EXAMPLE An e-commerce order Saga: reserve inventory, charge payment, then create the shipment. If payment fails after inventory is reserved, a compensating transaction releases the reserved inventory. Each step is idempotent and the orchestrator persists progress so it can resume or compensate after a crash.