Order, Payment and Inventory are separate services. How do you keep them consistent?

Inside one database a transaction gives you atomic all-or-nothing across the three tables. Across three services the only way to keep that is two-phase commit: a coordinator asks each participant to prepare (write and hold locks), then tells all to commit. It works, but participants hold locks while waiting on the network, and if the coordinator dies after prepare they are blocked indefinitely. Latency and availability both suffer, which is why almost nobody runs 2PC between services.

The practical alternative is a saga: a sequence of local transactions, each committed, with compensating actions for failure — reserve inventory, charge, and on payment failure release the reservation and cancel the order. The order is pending while this runs; the user sees that state. Each step publishes its outcome via an outbox so the state change and the event are written atomically in the same local transaction — see Distributed Transactions.