Distributed-Systems

A checkout flow that reserves inventory, charges a card, and creates a shipment touches three services, each with its own database. If the charge succeeds but the shipment service is down, the order is now paid with no shipment record, and nothing rolled back the inventory reservation either. That’s not an edge case. Any transaction that crosses a service boundary has this failure mode, because there’s no single database transaction wrapping all three writes. ...

Somewhere in your stack there’s a payment flow that died between “card charged” and “order marked paid,” and nothing remembers the gap. Or a “remind the customer in 48 hours” job that lived in a scheduler’s memory until the scheduler restarted. Or an onboarding that spans five services and three days, and the only way to answer “where is it now?” is grepping logs across all five and reconstructing the timeline by hand. None of these are exotic failures. They’re the standard cost of building long-running business processes out of queues, cron jobs, and status tables, and every team that does it long enough hits all three. ...