Design a Pre-Order System

Medium45 min
1 / 30
understanding•10 min read

Problem Statement: Pre-Order as a Deferred Fulfilment Contract

Frames the pre-order system as a time-bound inventory reservation with payment capture, not merely a product listing with a future date.

Problem statement

Design a pre-order system for an e-commerce platform that lets customers reserve upcoming products before their official release date. The system must handle deposit or full payment capture at pre-order time, manage guaranteed allocations against limited inventory, maintain a priority queue when demand exceeds supply, notify customers when items ship or when final payment is due, and seamlessly hand orders into the normal fulfilment pipeline on release day.

A pre-order is not a normal order with a later ship date. It is a deferred fulfilment contract between the platform and the customer, spanning days, weeks, or months. During that window the platform must hold a promise — a price, an allocation slot, a delivery estimate — while the underlying supply picture changes. Suppliers revise quantities, marketing changes the release date, customers cancel, and a viral social-media post can multiply demand a hundred-fold overnight. The system must absorb all of that without overselling, double-charging, or silently dropping a customer from the queue.

Why the problem is distinctive

A standard checkout flow is a short, synchronous transaction: browse, add to cart, pay, confirm. A pre-order stretches the same logical transaction across an extended lifecycle with multiple asynchronous phases. Each phase has different consistency, latency, and durability requirements.

At pre-order time the system must capture payment or a deposit, write an allocation record, and return a confirmation — all under a traffic spike that can be fifty times baseline. Between pre-order and release the system must track inventory revisions, process cancellations and refunds, handle price changes, and keep the customer informed. At release time it must capture any remaining balance, convert the pre-order into a standard order, and push it into the fulfilment pipeline — all within a tight time window before the warehouse cut-off.

The attached brief specifies four functional requirements: item listing with future release date, payment capture or deposit at pre-order time, priority queue or allocation logic for limited stock, and notification on shipping or final payment request. It also calls out four non-functional requirements: scalability under hype, integration with the normal order pipeline, an inventory reservation system, and analytics on pre-order demand. This answer designs for every one of them.

The four architectural planes

  1. Commerce plane: product catalogue, pre-order listing, pricing, cart, and checkout. This is the customer-facing surface.
  2. Reservation plane: inventory allocation, priority queue, guaranteed-versus-waitlist slots, and supplier quantity reconciliation. This is the correctness core.
  3. Payment plane: deposit capture, full payment, final balance collection, refunds, and integration with payment processors. This is the money boundary.
  4. Lifecycle plane: state machine from PRE_ORDER_PLACED through RELEASE_READY, FULFILMENT, DELIVERED, or CANCELLED. This is the orchestration backbone.

A strong interview answer keeps these planes separate. It lets the commerce plane degrade gracefully under load without corrupting the reservation plane, and it lets the payment plane operate with strong consistency while the analytics plane tolerates eventual consistency.

Key Highlights

  • •A pre-order is a deferred fulfilment contract spanning weeks, not a single synchronous transaction.
  • •The reservation plane must prevent overselling even under 50x traffic spikes.
  • •Payment capture may be split: deposit at pre-order, balance at release.
  • •The lifecycle state machine must survive supplier revisions, cancellations, and release-date changes.
  • •Four planes — commerce, reservation, payment, lifecycle — each with distinct consistency and latency needs.
Lead With the Deferred Contract
State in the first two minutes that a pre-order is a time-bound fulfilment contract, not a delayed checkout. This instantly distinguishes a pre-order architecture from a standard order pipeline and signals that you understand the multi-phase lifecycle.
Do Not Treat It as a Normal Order
A design that simply adds a future ship date to the standard order table misses the allocation queue, the deposit/balance split, the supplier reconciliation, and the release-day conversion. Each of those is a distinct engineering problem.

Section Rescue Kit

Buzzwords to use:

Deferred Fulfilment ContractOversell Prevention

Safe statements:

  • "I will separate the commerce surface from the reservation and payment planes so each can scale and fail independently."
  • "Before selecting databases, let me define which phases need strong consistency and which tolerate eventual consistency."
Design a Pre-Order System - System Design | WinJob | WinJob