A transaction that spans multiple services is implemented using the Saga pattern, which replaces a single distributed transaction with a coordinated sequence of local transactions and compensations.
Key Points: • The overall transaction is split into smaller steps, each owned and executed by a single service against its own database. • Each service completes its step and then signals success or failure to the next participant, either via a direct call or an event. • If any step fails, the services that already succeeded run their compensating transactions to undo their changes, in reverse order. • This can be coordinated with choreography (event-driven, no central controller) or orchestration (a central coordinator drives each step). • Because there's no cross-service lock, the system is eventually consistent during the saga rather than atomically consistent at every instant.
Example: For a multi-service checkout, the Payment service charges the card, then the Inventory service reserves stock; if inventory reservation fails, a compensating transaction refunds the charge, ensuring the customer is never charged for an item that couldn't actually be reserved.
Interview Tip: A concise interview answer is:
"I'd implement it with the Saga pattern: split the transaction into local steps owned by each service, and define a compensating action for every step that changes state. If a later step fails, the saga runs compensations in reverse order to unwind what already succeeded, giving eventual consistency without a distributed transaction."