Order Management System

Order lifecycle across payment, inventory and fulfillment

Design the order management system behind a retailer: take an order exactly once, carry it through payment, stock reservation and fulfillment with a saga, and keep its state right through cancellations, split shipments and peak sales.

Overview

An order management system (OMS) owns an order from the moment the customer presses Place order until the last item is delivered, canceled or returned. It does not charge cards, count stock or pack boxes itself; it asks the payment service, the inventory service and the warehouses to do those things, records what each one said, and decides what happens next.

The traffic is small compared with browsing: a few hundred orders a second even during a big sale. The hard parts are coordination and races. A retried checkout must not create a second order. A payment that succeeds after the stock hold has expired must not ship an item the shop no longer has. A cancel that arrives while the warehouse is packing must end with one answer, not two. And customer service needs to see the whole story of an order in one place.

Other topics cover the neighbors: the Payment System problem (authorization, capture, the ledger), the Warehouse and Inventory Management System problem (stock rows, reserving without overselling, picking) and the Returns and Refund Management System problem. This page is about the order itself and the workflow that ties those systems together. The Saga, Outbox Pattern, Idempotency and CQRS topics explain the general patterns.

Questions to ask first

Who places orders? — Shoppers on the web and mobile apps; one retailer, many products
Volume? — 2 million orders a day, 3 lines each, peak 10× average during a sale
Where do orders ship from? — Several distribution centers and some stores; one order may ship from more than one
When is the card charged? — Authorized at checkout, captured when items ship
Can customers change an order? — Address and quantities until the items are released to a warehouse; cancel any line until it ships
Who reads order history? — Customers (their own orders) and customer service agents (any order)
Consistency? — The order's own state is strongly consistent; read models may lag by seconds

What you will be able to do

Make order creation safe to retry, so one checkout produces exactly one order.
Draw the order and line state machine, including partial shipment, split shipments and cancellation.
Run checkout as an orchestrated saga with a compensating step for every action, and publish its events with an outbox.
Handle a stock hold that expires before payment finishes, and a cancel that races the warehouse.
Explain how the order is routed to fulfillment nodes and how customer service reads its history.

Key concepts

Idempotency keys
Order state machine
Line-level quantities
Saga orchestration
Compensating actions
Stock holds with expiry
Transactional outbox
Sourcing and split shipments
Optimistic concurrency
CQRS read model

Functional requirements

Create an order from a checkout, exactly once per checkout attempt
Authorize payment, hold and confirm stock, and release the order to fulfillment
Choose the fulfillment node for each line, splitting the order when needed
Track each line through released, shipped, delivered, canceled and returned
Let customers edit the address or quantities and cancel lines before they ship
Publish order events to warehouses, notifications and analytics
Show the full order history to the customer and to customer service

Non-functional requirements

No duplicate orders from retries; no order lost once acknowledged
Every order reaches a final state or an alert; no order stays stuck silently
Order placement under 2 seconds at p99, most of it payment authorization (a target we chose)
99.95% availability for placing orders (a target we chose)
Read models may lag; the order page after a change shows the change
Handle a 10× sale peak without overselling or dropping orders

Interview questions

How do you make sure one checkout creates exactly one order?
Walk me through the checkout saga, and what happens when payment is declined.
Why not use a distributed transaction (two-phase commit) instead of a saga?
How do you publish order events reliably?
A customer cancels while the warehouse is packing. What happens?
How do you choose where an order ships from?
How do split shipments affect payment?
How does customer service see the full history of an order?
How do you prepare for a big sale?