Design the service that drives a confirmed order through its fulfillment lifecycle — capturing payment, allocating inventory, dispatching a warehouse pick-pack, and handing off to a shipping carrier — coordinating several independent downstream services.

Operating context. After checkout, an order enters a defined sequence of steps, each owned by a different service (payment, inventory, warehouse management, shipping). Any step can fail or be slow, and a later failure must undo the effects of earlier successful steps — release reserved inventory, void an authorization. An order may split across warehouses, so parts of it can progress independently. The system carries money and stock, so every step must be safe to retry, and no order may silently get stuck. Peak is around 5000 new orders/sec (500/sec steady), each averaging six steps.

Out of scope. The internals of the payment, inventory, warehouse, and carrier services; fraud scoring; customer-facing order UI; and returns/refunds after delivery. Assume each downstream exposes an idempotent request API and emits completion callbacks.

What to produce. A high-level architecture covering: how the ordered, multi-step workflow is modeled and persisted, how each downstream step is invoked idempotently and its result awaited, how compensation (rollback) is triggered when a later step fails, how partial/split fulfillment is represented, how stuck orders are detected and escalated, and how the whole thing survives an orchestrator restart. Sketch the components and trace one order — including one that fails midway and compensates.