Design Cart, Checkout & Orders

Understanding the problem

This is the buy flow and it is the most recognizable system a retailer going tech-first is built to run. Every other retail design in this guide, inventory, catalog, fulfillment, hangs off it or feeds it. The cart is where a shopper's intent gathers. Checkout is where that intent turns into money and a commitment to ship. The order is the record the rest of the company acts on. Three parts, one loop. Get this loop right and the storefront makes money reliably. Get it wrong and you either drop carts, double-charge cards or fall over on the one day the volume matters most. The interviewer is not checking whether you can wire three services together. They want to know whether you can make the buy flow land exactly once when parts of it fail.

How hard the round pushes depends on the level. Below senior it is often folded into a low-level design or a coding screen and in one loop it shows up as a ninety-minute machine-coding round where you model the cart cleanly in code. From senior up it becomes a genuine architecture conversation, run by a principal or staff engineer who works with you as a fellow builder rather than an examiner. The prompt starts small and grows under you. First it is one shopper and one cart. Then it is a checkout that has to reserve stock and charge a card without a distributed lock. Then a doorbuster just dropped and the same button is being pressed a thousand times a second. Expect the push to land where a retailer feels it: the double charge, the lost cart and the peak.

The Walmart angle

This is the literal buy flow behind walmart.com, the money path for hundreds of millions of shoppers, so the bar is reliability, not cleverness. The round rewards a design that treats never double-charging and never losing a cart as hard correctness rules, and everything else as negotiable. That is how the storefront is graded in production. An interviewer here has almost certainly operated a piece of checkout or orders, which means a generic three-box answer gets probed fast and a design that names idempotency, compensation and peak degradation lands hard. Skip over-engineering the clever parts. Spend your effort on the boring guarantees: one order per intent, one charge per order, a cart that follows the shopper everywhere. Design for that and every box has a reason a retail engineer will recognize.

Functional requirements

Keep the core small and let the interviewer stretch it. There are five jobs. First, manage the cart: add, update and remove items and keep it persistent across devices and days. Second, price the cart at checkout: line totals, tax and promotions, computed against the live catalog. Third, place the order, which is the crux: reserve the stock, authorize payment and create the order as one all-or-nothing outcome. Fourth, run the order through its life, from placed to paid to fulfilled and fan that out to the rest of the company. Fifth, make the whole place-order path idempotent, so a retry never buys twice. One requirement outweighs the rest. Placing the order safely, exactly once, under failure and retries, is where the design either holds or double-charges.

Non-functional requirements

Reason each target from what the buy flow is for. Correctness leads and it is about money and trust. A card must never be charged twice for one order and an order must be placed exactly once no matter how many times the request arrives. That is the hard line, and it is narrow. Browsing a catalog can be a little stale. A cart total can be recomputed. But the charge and the order cannot be duplicated. Durability comes next and it is unusual for a cart. A cart is not a session that can evaporate. It is state the shopper owns, worth real revenue. It has to survive a server restart, a switch from phone to laptop and days of sitting idle. Then availability under peak, because the buy flow has to stay up on the day it is stressed hardest, and it should bend by shedding browse long before it ever slows a checkout. Latency matters least of the four here, though a sluggish checkout costs conversions, so the read paths lean on cache and the write path stays lean.

The slack worth banking now is that browse and cart reads can be fast and slightly stale and the place-order path is where you spend for truth. A cart badge that is a second out of date is fine. A product page that shows a price the checkout will recompute is fine. What cannot be loose is the reserve-charge-record step, so that is the one path that runs as a carefully-ordered transaction with idempotency threaded through it. We will spend that slack deliberately later: caching cart reads, letting a waiting room meter the crowd and letting the event log absorb a burst rather than shedding it onto the order service.

• never double-charge a card. The hard money-correctness bar: exactly one payment authorization and capture per order, even when the request is retried three times.
• never lose a cart. A cart is durable state owned by the shopper, so it survives a server restart, a device switch and days of idle, not a session that can evaporate.
• exactly one order per intent. A retried place-order returns the same order rather than creating a second one, no matter how the retry arrives.
• peak holds the buy flow up. On a Black-Friday doorbuster the money path stays whole; the system degrades browse and coarsens stock counts before it ever slows checkout or payment.

Sizing the buy flow

Put rough numbers on the board before the architecture and derive them out loud, because a good interviewer redoes the arithmetic with you. Treat every figure as an illustrative teaching estimate. Start with shoppers. A national storefront serves on the order of a couple hundred million customers a week. On a heavy day, call it tens of millions of active shoppers, and a healthy fraction of them have a cart open at once. That is millions of live carts at any moment, each small, a handful of line items, but each one durable state that has to follow its owner across devices for days. So the first sizing fact is not a rate, it is a population: millions of open carts to keep, most of which never check out.

Now turn shoppers into orders and the retail calendar sets the peak. On an ordinary day orders trickle in at a steady rate. On Black Friday the storefront takes millions of orders across the day and the ugly part is that they do not spread evenly. A doorbuster drops at a set minute and the order rate on that minute jumps to thousands a second while a normal minute sees a few hundred. An order is never one write. Each one fans out into a coordinated sequence: reserve inventory, authorize payment, create the order, then emit events downstream. So thousands of orders a second is really tens of thousands of cross-service steps a second, every one of which has to be safe to retry. Add-to-cart writes run several times the order rate, because most carts never convert, so the cart path takes tens of thousands of writes a second on its own. And cart reads dwarf all of it, since every page paints the cart. The last multiplier is the nastiest. When the site slows under the spike, shoppers and clients retry, so the same order intent can arrive two or three times. Only idempotency keeps that from becoming two or three charges.

• Live carts: millions open at peak. a cart per active shopper, most never converting, each small but durable and required to follow its owner across phone, app and desktop for days. This is a population to keep, not a rate.
• Peak order rate: thousands/sec on a doorbuster. a set-minute drop, not a smooth ramp and each order is a multi-step cross-service transaction, so the real step rate is an order of magnitude higher.
• Hot-item contention: thousands of checkouts on one SKU. a doorbuster funnels the whole crowd at a single item, the exact key the inventory reservation has to serialize to avoid oversell. The concentration, not the aggregate, is the danger.
• Retry amplification: same intent arrives 2-3x. a slow spike makes clients and shoppers retry, so place-order sees each intent several times. Idempotency collapses the duplicates into one order and one charge.

Two lines in that grid set the agenda. Millions of durable carts have to live somewhere cheap to read and impossible to lose and the place-order step has to survive both the raw peak and the retry storm without ever charging twice. So the design keeps a few things true at once. The cart path stays fast and durable. The checkout path is safe to retry and unwinds cleanly on failure. The order fans out exactly once. And the whole thing bends under peak by sacrificing browse before buying. Each deep dive below is one corner of getting that right.

The set-up

Core entities

Name the objects before drawing anything. Five carry this design and the one to pin down first is the order intent, because it is what the idempotency key names and what a retry has to resolve back to.

Pin where each piece lives, because the interviewer will ask. The carts land in a durable store keyed by customer, with a hot copy in cache. The access pattern is a point read and point write by that identity a great many times over. The order intent and the order state live in the order service store, keyed by order id and by the idempotency key. A retry can find an in-progress order instead of starting a new one. The payment lives behind an external gateway, referenced by the order and the key, never in our own tables. And the order events flow through a durable log, which downstream teams fold at their own pace.

API

Keep the external surface thin and let the shape of each call say which regime it belongs to. Cart calls are frequent, cheap and forgiving. The checkout call prices the cart and hands back a token. The place-order call is the strong one and everything about it exists so a retry lands on one order. Reference these by name in the deep dives.

One of these carries the design. The place-order call is the strong path and everything about it exists to guarantee that when the request arrives more than once, the shopper ends up with exactly one order and exactly one charge. It reserves, authorizes and records as one coordinated outcome, keyed by the token minted at checkout and it is the only call worth the cost of a careful distributed transaction. The cart calls are the mirror image: frequent, cached and safe to be a touch stale, because nothing binding is decided until checkout recomputes it. The order-status read is the payoff a shopper watches and the event stream is how the order tells the rest of the company what happened, once and only once.

High-level design

Follow the shopper one hop at a time. A Shopper builds a cart through the Cart service, which persists it to the Cart store and reads it back from cache. When they commit, the Checkout orchestrator takes over. It prices the cart, then drives the place-order transaction. It reserves units through the Inventory service, authorizes money through the Payment gateway and creates the record in the Order service. The order writes its state change and an event together and the Order events log fans that out to Fulfillment + notify and the rest. The diagram colors each box by role: blue for the shopper and the external gateway, violet for the services, amber for the event log, green for the store. The walkthrough reuses the same tags.

1) The shopper builds a cart. The Shopper adds, updates and removes items through the Cart service, which persists to the Cart store and serves reads from cache. This path is high-volume and forgiving: a cart badge a second stale is fine, because nothing binding is decided yet. What is punted here is how the cart stays durable and follows the shopper across devices, which the first deep dive owns.

2) Checkout prices the cart. When the shopper commits, the Checkout orchestrator reads the cart, recomputes line totals, tax and promotions against the live catalog and hands back a quote plus an idempotency key. Recomputing rather than trusting the cart is deliberate, because a price or a promo can have moved since the item went in. The cart carried intent; checkout binds the numbers.

3) Place-order runs the transaction. The Checkout orchestrator drives the crux: reserve units through the Inventory service, authorize a hold through the Payment gateway and create the record in the Order service, all anchored to the same key. If any step fails, it unwinds the earlier ones. What is deferred here is how that stays exactly-once under retries and unwinds cleanly on a partial failure, which the second deep dive owns.

4) The order drives the company. The Order service advances the order through its state machine and, on each transition, writes the state and an event together, which the Order events log carries out to Fulfillment + notify and inventory. This is where a placed order becomes shipping, a charge capture and a text message. The trap being deferred is the dual-write between saving the order and publishing its event, which the third deep dive owns.

5) Peak bends the flow, not the money path. Sitting over all of it is admission control. When a doorbuster drops, a waiting room meters the crowd into the buy flow at a rate the backend can serve. The system sheds browse and coarsens stock counts before it ever slows a checkout. Reliability first, cleverness never. The hard part it defers is how the buy flow degrades by priority and survives hot-item contention, which the fourth deep dive owns.

Technology choices

A box with a name on it is not a decision yet. Back each with a real tool, argue why that kind of tool suits this workload and know where it buckles under this load. Slot a mainstream choice into each one and the follow-ups will come from the failure modes.

• Cart store is a durable wide-column store with a cache in front: Cassandra keyed by customer identity for the durable cart, Redis holding the hot copy so the common read is a millisecond. Right because a cart is small, read constantly, written often and must survive restarts and days of idle and the one access pattern is a point read and point write by customer. The failure story is a cache miss falling back to Cassandra, a little slower but never wrong and the durable copy means a cart is never lost to an eviction.
• Checkout orchestrator is a saga orchestrator. This stateful coordinator drives reserve, authorize and create-order in order, and runs compensations in reverse on any failure. It is keyed by the idempotency key so a retry resumes rather than restarts. It is right because the alternative, a two-phase commit locking three services together, is slow and brittle at this scale and this failure rate. The failure to plan for is the orchestrator crashing mid-saga, which the durable key and the recorded step state let a retry pick up from instead of running twice.
• Order events is a transactional outbox on Kafka. An order state change and its event commit together to an outbox table. A relay publishes to Kafka, which fans out to inventory, fulfillment and notification. Kafka is right because it is the retailer event spine and it decouples the order service from every consumer, so a burst queues in the log instead of knocking the order service over. The failure mode to name is a consumer lagging: its effect trails the order state and idempotent dedup by event id makes the eventual catch-up clean.
• The payment gateway is an external authorize-and-capture service fronted by an idempotency key: authorize a hold at checkout, capture on confirm, void on compensation. It is right because the card networks and PCI vaulting are boundaries you want to keep outside your services and the key lets the gateway collapse duplicate requests into a single charge. The failure to design for is a lost authorization response, where you do not know if the money moved, reconciled against the gateway by the key rather than retried into a possible second charge.

The Walmart angle

Ground the design in the retailer real stack when the interviewer asks and be specific about the event backbone. The order fan-out rides a Kafka event spine that carries an enormous message volume every day at four-nines availability, which is precisely what lets a Black-Friday burst queue instead of toppling the order service. The inventory reservation is the same single-owner-per-item trick from the inventory design: every item routes to one partition and one owner, so a doorbuster on one SKU is serialized rather than raced. This spine hands you decoupling and durability. The saga, the idempotency key, the compensations and the outbox are still yours to design. Naming the event backbone as the buffer and saying plainly that strong consistency belongs on the reserve-and-charge while browse can be eventual, is the reliability-first answer this round rewards.

Potential deep dives

Everything still on the table is won here, in the dives. A retail buy-flow round almost always pushes on the same four corners. How a cart stays durable and follows the shopper. How place-order lands exactly once across three services. How the order drives the company without dropping a message. And what the whole thing does when a doorbuster hits. The idempotent checkout is the crux, so it gets the most room.

1) The cart and where it lives

Start at the cart, because it is the entity most people underrate. A cart looks like a scratchpad, so the instinct is to keep it wherever is easiest and move on. That instinct is the trap. A cart is durable state the shopper owns, it is worth real revenue and it has to follow them from the phone at lunch to the laptop at night. Walk where it can live, because the difference between a cart that vanishes and one that follows the shopper is the whole first impression of the buy flow.

2) Checkout as a distributed transaction

The dive turns on one hard fact. Placing an order takes three services that all have to agree: inventory has to set the units aside, payment has to secure the money and the order service has to record the sale. Any one of them can fail or time out while the others succeeded. And the shopper, staring at a spinner, will tap the button again. So the hard part is making the whole thing land exactly once when parts of it fail and the caller retries. Retries are the weather here. Walk it slowly, because arriving at the safe design for the right reason is the point of the dive.

The Walmart angle

The idempotent place-order is the single decision this round is graded on, because it is the money path a retailer runs for hundreds of millions of shoppers. An interviewer wants to hear two words out loud, idempotency and compensation and to hear you thread one key from the first checkout tap through the reservation, the payment authorization and the order record. Treat the retry as the normal case. At peak the site is slow and everyone is retrying at once. Say plainly that the authorization carries the key, so the gateway dedups it into a single charge. A lost payment response is reconciled instead of retried. Strong consistency belongs on reserve-and-charge while browse stays eventual. That is the reliability-over-cleverness reasoning that separates a retail answer from a generic three-box diagram.

3) The order service and the write path

The saga produced an order. Now that order has to drive the rest of the company: inventory decrements for real, fulfillment picks and packs, notification tells the shopper. The order also has a life. It moves from placed to paid to fulfilled to delivered or branches to cancelled and returned. Two traps hide in that handoff. The order is one record many things want to change and the moment you both save it and tell someone about it, you have a dual-write that can quietly drop the message.

4) Black-Friday scale and graceful degradation

The last dive is the day the whole design exists for. A doorbuster drops at a set minute and a national crowd hits place-order in the same second. Two ugly things happen at once. The aggregate load spikes far past a normal day and worse, it concentrates, because the crowd is not spread across the catalog, it is all reaching for the same few items. The buy flow has to stay up, stay correct and decide what to sacrifice first when it cannot serve everyone. Plan the sacrifice in advance, because the peak is not the moment to invent one.

The Walmart angle

Black Friday is the buy flow's whole reason for existing, not a once-a-year load test bolted onto it, and reliability over cleverness is the stance this round is graded on. The Kafka event backbone carries an enormous daily message volume at four-nines availability. A spike has somewhere to queue instead of knocking a system over. And the single-owner reservation keeps a doorbuster on one SKU from becoming an oversell or a melted node. What reads as real here is seeing the peak as a different animal from a busy Tuesday, not the same shape scaled up. The spike in total load and the concentration onto a few hot items are two different problems with two different answers. A waiting room and a log absorb the flood, while a single owner handles the hot item. Naming that split and naming what you degrade before you ever touch checkout, is the reliability-first answer the round rewards.

What is expected at each level

This design carries a lot of surface and the rungs separate on how much of it you own before anyone asks. Below senior the buy flow often arrives as a low-level design or a ninety-minute machine-coding round, where the bar is a clean cart model rather than a distributed architecture. At senior and above it becomes a leveling gate. Read the rungs as a climb: a coherent end-to-end flow at mid, the idempotent checkout and the durable cart owned at senior and the outbox and the peak-degradation story carried at staff.

Mid-level engineer

Spend your time on breadth, about eighty to twenty. Breadth over depth here. Reach one coherent end-to-end path: a shopper builds a cart in a cart service, checkout prices it and reserves stock and charges a card and an order gets created and drives fulfillment and notification. Model the cart cleanly, a Cart of CartItems and an Order that is created from it, because in the low-level round that model is most of the grade. Name the double-charge risk at all. When the interviewer asks what happens if the shopper taps place-order twice, reach for an idempotency key rather than shrugging. A working buy flow you can defend, with the interviewer filling in the harder corners, clears this rung.

Senior engineer

Now the balance tips to depth, roughly sixty to forty and this is the level the round is tuned to. Raise the hard facts yourself. Make the cart durable and keyed by customer and explain the guest-to-login merge without being asked. Drive checkout as a saga and put the idempotency key on the board as the thing that makes place-order safe to retry, with compensations that release the reservation and void the authorization on failure. Make the consistency call deliberately: strong on reserve-and-charge, eventual on browse and say why. Arriving at a near-complete buy flow whose double-charge guard, cart durability and saga you flagged on your own is the bar here.

Staff and beyond

At this level depth dominates the whole picture, about forty to sixty. Own the write path end to end. The transactional outbox closes the dual-write hole. Consumers stay idempotent by event id for exactly-once effect, and the order is a state machine other systems only ever react to. Carry the peak story. A waiting room meters the crowd, and priority shedding sacrifices browse before checkout. The log is the buffer that keeps a burst from becoming a backlog, with the hot-item contention handed to the single-owner reservation. Hold the idempotency key, the compensation set and the degradation priorities as deliberate levers and know what bends under pressure, browse to a coarse signal, the money path never. You drive the design and the interviewer course-corrects instead of stepping in to save it. The bar is holding the cart, the checkout transaction, the order write path and the peak as four separate levers while never-double-charge and never-lose-a-cart survive every refinement.