Problem Statement & Context
What we are building and why order management is complex
Problem Statement & Context
An Order Management System (OMS) orchestrates the entire order lifecycle from checkout to delivery. It sits between storefront, inventory, payment, fulfillment, and shipping, ensuring every state transition is correct, auditable, and customer-visible. It is the source of truth for what state an order is in.
The journeys
- Customer: place → confirmation → allocated → pick/pack → ship → track → deliver → cancel/return → refund.
- Operations: validate payment + inventory → allocate fulfillment → emit shipment/tracking → handle exceptions, cancellations, returns.
Why this is a classic system design question
An OMS is a distributed workflow with three hard properties at once: the lifecycle is a state machine with strict transition rules (no skipping or reversing states); every step must be idempotent and retry-safe (downstream calls time out and get retried); and multiple services must agree (inventory, payment, shipping) without a global transaction. The load-bearing idea is that an order is best modeled as an append-only event log driving a state machine, coordinated across services by a saga (do-then-compensate) rather than a two-phase commit — because you cannot hold a distributed lock across a payment processor, a warehouse, and a carrier for the life of an order.
Scale anchors
30M orders/day, 500M status events/day (~16 events/order); 8% returns, 2% cancellations; 10× promo spikes. These drive sharding, event streaming, and idempotency design.
Key Highlights
- •An OMS orchestrates the order lifecycle from checkout to delivery, sitting between storefront/inventory/payment/fulfillment/shipping — the SOURCE OF TRUTH for what state an order is in (every transition correct/auditable/customer-visible)
- •Journeys: customer (place -> confirm -> allocated -> pick/pack -> ship -> track -> deliver -> cancel/return -> refund), operations (validate payment+inventory -> allocate fulfillment -> emit shipment/tracking -> handle exceptions/cancellations/returns)
- •A distributed workflow with three hard properties at once: a STATE MACHINE with strict transition rules (no skipping/reversing), every step IDEMPOTENT + retry-safe (downstream calls time out + retry), MULTIPLE SERVICES must agree (inventory/payment/shipping) without a global transaction
- •The load-bearing idea: an order is an append-only event log driving a state machine, coordinated across services by a SAGA (do-then-compensate) not 2PC — you can't hold a distributed lock across a payment processor, a warehouse, and a carrier for the life of an order; anchors 30M orders/day, 500M events/day (~16/order), 10× spikes
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I'll define the order state machine before deep-diving services."
- "All transitions will be idempotent and replay-safe."