How do you handle transactions across services?

Direct answer

What a strong answer covers

How it works

There is no commit that spans two databases owned by different services without a coordinator that becomes a bottleneck and a single point of failure. Instead the workflow is decomposed: each service performs one local atomic transaction and publishes a durable event or accepts an idempotent command; a saga, orchestrated by a coordinator or choreographed through events, advances step by step and runs compensating actions when a later step fails. The state of the workflow is stored explicitly so operators can see stuck instances, and every step tolerates duplicates and retries.

Example

Placing an order reserves inventory, charges the card, and creates a shipment in three services. The orchestrator writes the order in state PENDING, sends ReserveStock, then ChargeCard; if the charge fails it sends ReleaseStock as compensation and marks the order FAILED. The outbox pattern guarantees each service’s event is published if and only if its local transaction committed.

Common mistakes

• Calling three services in a row from one request handler and hoping none fails midway.
• Designing compensations that assume the original action definitely happened.
• Leaving no record of in-flight sagas, so a crash strands orders in an unknown state.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.