An order flow spans payments, inventory and shipping, each with its own database. How do you keep the whole thing consistent?

You give up a single distributed transaction and use a saga: a sequence of local transactions where each step publishes an event that triggers the next, and every step has a compensating action to undo it. Consistency becomes eventual, so the design work is deciding what to compensate, what to retry and what to escalate to a human. Model the flow explicitly, either choreographed through events or coordinated by an orchestrator.

A two phase commit across three services and three databases means holding locks across the network and a coordinator that can block everything if it dies, so I would not do it. Instead the flow becomes a saga. Each service does its own local transaction and emits an event, and each step has a defined compensation: if shipping cannot allocate, we release the inventory reservation and refund or void the payment. The important thing is that compensation is a business action, not a rollback; a refund leaves a visible record and that is correct. For anything with more than about three steps I use an orchestrator rather than pure choreography, because with choreography the actual flow lives nowhere and no one can answer where an order is stuck. An orchestrator gives me one state machine, timeouts per step and a queryable status. Every step is idempotent and retried with backoff, and anything that exhausts retries lands in an operations queue with the order id, because some failures genuinely need a person.