Design Order, Cart & Inventory

Understanding the problem

This is Chewy's home turf. So the framing matters as much as the design. Chewy sells pet food, medication, and other supplies, and the interviewer wants to see you reason through a real retail checkout, not audition a distributed-systems thesis. Reports from the loop are consistent on the altitude: outline the database schemas and the API endpoints, reason through a multi-component system, and keep it grounded. One candidate summarized the system-design round as "minimal." That is a hint about scope, not a license to be vague. Minimal means you are not expected to shard the world, but you are very much expected to get correctness right where money and stock are on the line.

So read the problem for where it is genuinely hard rather than where it is merely big. Browsing the catalog is a read-heavy, cacheable problem that any e-commerce site solves the same way, and it is not what this round turns on. The hard parts are narrow and specific. Two customers must not both buy the last bag of a food when one unit is left. A customer who taps "place order" twice must not get charged twice. And Autoship has to fire thousands of orders on schedule with no human touching them. Name those three early and the rest of the design falls into place around them.

The Chewy angle

Chewy runs a pragmatic, ship-oriented loop. The stack recruiters name is Java, Spring, and React, and the rubric rewards a design that is clear and correctly right-sized over one that is clever. The system-design round is often a single hour, and for a SWE I it can be light. Treat that as freeing, not limiting. It means you can spend your minutes on the inventory-correctness and Autoship pieces that distinguish a retail design. Skip the reflexive "and then we add Kafka and shard by user" tour; it adds nothing here. Know Autoship by name before you walk in: it is Chewy's auto-reorder subscription, and it is the one component of this design that is genuinely Chewy's rather than generic e-commerce.

Functional requirements

Propose a tight core and let the interviewer widen it. The spine is add to cart, place an order against real stock, and reorder on a schedule.

Non-functional requirements

Attach a target to each one and reason about it out loud. The first is correctness of stock, and it is the whole round. Inventory has to be strongly consistent at the moment of purchase: the count you decrement is the count that decides whether the sale is allowed, and a stale read here means an oversell. Relax everywhere else. Not here.

The second is that placing an order must be exactly-once from the customer's point of view. A double-tap, a retried request after a timeout, or a browser back-button resubmit must produce one order and one charge, never two. This is an idempotency requirement, and it is cheap to get right if you plan for it and expensive to bolt on later.

The rest are ordinary retail targets. Cart and checkout should feel instant, so aim for reads and writes in the low tens of milliseconds, which means the cart lives in a fast store, not buried behind a slow join. The order write itself can take a beat longer, since a customer will wait a second for a confirmation screen. Availability leans on reads. Browsing and adding to cart must stay up even if a fulfillment center's inventory feed hiccups. A slightly stale "in stock" during browse is fine as long as the final decrement at checkout is exact. Autoship is a background job, so it trades latency for reliability: a subscription order can fire minutes late, but it must fire, and exactly once per cycle.

• Strong Inventory consistency at purchase. The decrement decides the sale; a stale read here is an oversell.
• Exactly-once Order placement. A retry or double-tap yields one order and one charge.
• < ~50 ms Cart read and write. Checkout should feel instant, so the cart lives in a fast store.
• Reliable, not fast Autoship firing. A recurring order can run late, but must fire once per cycle.

A quick sizing pass keeps everything at the right altitude. Assume something like 20 million active customers, a catalog on the order of 100,000 SKUs, and daily orders in the low millions at peak. None of those numbers force exotic infrastructure. A catalog of 100,000 SKUs and a few million orders a day fits comfortably in a well-indexed relational database. The write rate averages tens of orders a second with holiday spikes into the hundreds. That is a load a single primary Postgres handles with room to spare, which is exactly why the interview stays at schema and API level rather than sharding strategy.

The set-up

Core entities

Name the objects the system moves before drawing anything. Five carry the design, and the split between the SKU and its per-warehouse stock is the one to get right.

Now the storage decisions, named concretely, because a design that says "a database" reads as junior. Orders, order lines, and inventory belong in Postgres. They are relational, they need transactions, and inventory correctness depends on the ability to lock a row and decrement it atomically, which a relational engine gives you directly. Orders are keyed by orderId and indexed by customerId for a customer's history; inventory is keyed by the composite (sku, fcId). There is nothing to shard at these volumes, so one primary with read replicas is the honest answer.

The cart is different. It is small, per-customer, written constantly as people fiddle with quantities, and it does not need heavy relational guarantees, so it belongs in a fast key-value store like Redis or DynamoDB, keyed by customerId. Keeping the cart out of the transactional database keeps the checkout path clean and the cart snappy. Autoship subscriptions live in Postgres too, since firing them is a transactional job and nextRunAt is the column a scheduler queries. Product catalog data is read-heavy and cacheable and sits behind its own service, which this design treats as a dependency it reads from.

API

Keep the interface small and let each endpoint do one clear thing. The cart endpoints are chatty and cheap; the order endpoint is the one that carries the weight, and it takes an idempotency key so a retry is safe.

Two design choices are worth saying aloud. First, POST /v1/orders takes an Idempotency-Key header, a unique token the client generates once per checkout attempt, so the server can recognize a retry and return the same order instead of creating a second one. Second, availability shown during browse comes from a read replica and is allowed to be slightly stale, but the decrement at checkout goes through the primary and is exact. Naming that split early prevents the classic mistake of trusting a browse-time stock read at purchase time.

High-level design

Build it one requirement at a time and aim for a working skeleton before polishing anything. The system is a handful of focused services over the two stores from the set-up, plus a background scheduler for Autoship. The diagram codes each box by role: blue for Customer and outside dependencies, violet for our services, amber for scheduling and queues, green for stores. The walkthrough below tags each component the same way.

1) Build the cart. The Customer adds items, and the Cart service writes the basket to the Cart store keyed by customer, reading current price and availability from the Catalog service to display on each line. Nothing here is committed or reserved. Prices are shown live and stock is shown best-effort, because a cart is a wish list, not a promise. The bottleneck we are punting: the availability shown on a cart line can be stale by the time the customer checks out, so the real stock decision has to happen at checkout, not here. That is the overselling deep dive.

2) Place the order. The Customer posts to the Order service with an idempotency key. The order service asks the Inventory service to reserve and decrement stock, which locks the exact (sku, fcId) row in the Inventory DB and subtracts the quantity inside a transaction. It then charges through the Payment gateway, writes the immutable order to the Order DB, and returns a confirmation. This is the one place strong consistency is non-negotiable, because the decrement is what decides whether the sale is allowed. The bottleneck we are punting: the reservation, the charge, and the order write are three separate steps that can each fail independently. Coordinating them so a failure never strands stock or double-charges is a deep dive.

3) Hand off fulfillment. Once the order is written, the Order service drops a message on the Fulfillment queue and returns immediately. The warehouse and shipping systems pick the order up asynchronously, so the slow physical work never sits on the customer's confirmation path. A queue is the right tool because fulfillment is bursty and downstream, and it must not fail the order if a warehouse system is briefly slow. What we keep off the hot path is every second of picking and packing and label printing.

4) Fire Autoship. Separately, the Autoship scheduler periodically reads the Autoship DB for subscriptions whose nextRunAt has passed and drives each one through the same Order service path, then advances nextRunAt to the next cycle. A recurring order is just an order with no human present, so it reuses the reservation, charge, and write logic rather than duplicating it. The bottleneck we are punting: a scheduler that fires without a customer watching must be exactly-once per cycle. It must also handle a subscription whose item is now out of stock or repriced. That is the Autoship deep dive.

Technology choices

Each box is a category so far. Name a real tool for each and be ready to defend the category, because Chewy's system-design round leans on judgment more than on novelty. The theme: these are load levels a mature relational stack handles directly, so the right move is boring, correct tools, and a clear reason for each.

• The Order service, Cart service, and Inventory service are stateless Spring services behind a load balancer, which matches the stack Chewy runs. Stateless means any instance serves any request and a dead one drops out of rotation, so scaling is just adding boxes. The state that matters lives in the stores, not the services.
• The Order DB and Inventory DB are Postgres, one primary with read replicas. Orders and inventory are relational and need transactions, and the inventory decrement needs a real row lock, which Postgres gives you with SELECT ... FOR UPDATE or an atomic conditional UPDATE. If the primary fails, a replica is promoted; the brief write pause is acceptable because a customer will retry a checkout, and the idempotency key makes that retry safe. At a few million orders a day there is nothing to shard, so proposing sharding here reads as over-building.
• The Cart store is Redis or DynamoDB, keyed by customerId. Carts are tiny and disposable, so a fast key-value store beats a relational table, and a lost cart is a minor annoyance rather than a lost order. Set a TTL so abandoned carts expire on their own.
• The Fulfillment queue is SQS or Kafka. A durable queue decouples the fast checkout from slow warehouse work and absorbs holiday bursts. The failure answer is built in: a message that fails processing retries with backoff and lands in a dead-letter queue for inspection, so a flaky downstream never fails a confirmed order.
• The Payment gateway is an external processor called with an idempotency key. We do not store raw card data; we hold a token and a charge id. The probe here is what happens on a timeout, and the answer is that an idempotent charge call plus a reconciliation check turns a "did it go through?" ambiguity into a safe retry.
• The Autoship scheduler is a cron-driven job or a managed scheduler querying nextRunAt. It needs no streaming machinery, because the work arrives on a predictable cadence and the volume per run is bounded. Idempotency per cycle, not throughput, is the thing to design for.

The Chewy angle

Say the boring-on-purpose part with conviction, because it is exactly what Chewy's rubric rewards. A candidate who answers a few-million-orders-a-day retail flow with sharded databases, an event-sourced ledger, and a stream processor has pattern-matched "system design" to "big distributed system" without checking the numbers. That reads as the opposite of the pragmatic, ship-oriented engineer Chewy hires. Instead, size the load, notice a single Postgres primary handles it, and spend your minutes on the inventory correctness and Autoship logic a pet-supply retailer lives or dies on.

Potential deep dives

The skeleton is deliberately calm. The signal is in the next four questions, and the interviewer will pick one or two and push. The first is where most of the round is won, because it is the one place correctness is truly on the line.

1) How do we never oversell a SKU under concurrent checkout?

Here is the tension, stated plainly. Two customers both have the last unit of a SKU in their carts, because the cart showed each of them "in stock" from a slightly stale read. They both hit checkout within the same second. If both are allowed to decrement, you have sold one bag of food twice. Someone gets a cancellation email, which for a customer whose dog is out of food is a real failure. The whole point of the checkout path is to serialize that last unit so exactly one of them wins.

Put a number on why this is not rare. A hot SKU during a promotion might see hundreds of checkouts a minute against a stock count in the dozens. Once available stock nears zero, the odds that two checkouts race for the same row stop being theoretical, so the decrement has to be correct under contention, not merely correct in the quiet case.

The good tier fixes the race, which is the core of the question. What forces the upgrade is that checkout is not one step. Reserve, charge, and record can each fail independently, and a design that decrements stock and then loses the payment has quietly removed a unit from sale that nobody bought. The great tier adds the reservation lifecycle that makes the whole transaction safe.

The Chewy angle

This is the deep dive to reach for unprompted, because it is where a retail design earns its keep and where Chewy's "operate in the details" instinct shows. The interviewer is not looking for a distributed-locking lecture. They want to see you recognize that a bag of dog food is a single physical unit and reach for the atomic conditional decrement without fumbling the race. Then extend it to a reservation, so a failed payment does not quietly eat inventory. Say the UPDATE ... WHERE available >= quantity line out loud; it is the sentence that tells the interviewer you have built this.

2) How do we make placing an order exactly-once?

The failure is common and expensive. A customer taps "place order," the request succeeds on the server, but the response is lost to a dropped connection, so the app retries. Or an impatient shopper double-taps. Without protection, that is two orders, two charges, and two decrements for one intended purchase. The fix is to make the order write recognize a retry as the same request rather than a new one.

Idempotency and the reservation from the first dive fit together cleanly: the key makes the whole reserve-charge-write sequence safe to retry, and the reservation makes each attempt safe to roll back. Together they turn a fragile multi-step checkout into one that tolerates the messy reality of mobile networks.

3) How does Autoship place recurring orders reliably?

Autoship is the piece that makes this Chewy's design rather than any store's. A customer subscribes to a 30-lb bag of food every four weeks, and from then on the system places that order on schedule with no one watching. The requirements shift: latency stops mattering (an order can fire minutes late) and reliability becomes everything (it must fire once per cycle, and it must handle the world having changed since the customer subscribed).

Size it so the mechanism is clear. If millions of active subscriptions spread across their cycles, a given hour might have tens of thousands due. That is a steady trickle, not a firehose, which is why a scheduled job querying nextRunAt is the right shape and a streaming system is not.

The Chewy angle

Autoship is central to how Chewy retains customers, so an interviewer who brings it up is watching whether you treat it as a real product with real edge cases or as a toy timer. The "put customers first" instinct is the tell here. A subscription that silently skips a cycle because a SKU blipped out of stock is a dog that goes hungry. Reliable firing and out-of-stock handling are core to this design. Lead with exactly-once firing and graceful handling of stock and payment changes, and you are speaking Chewy's language.

4) Where does the cart live, and how do carts merge?

A lighter dive the interviewer may reach for if there is time. The cart has softer guarantees than the order, which is exactly why it earns a different store, and the one genuinely fiddly case is a guest who builds a cart and then logs in.

Keep the cart in a fast key-value store (Redis or DynamoDB) keyed by customerId, with a TTL so abandoned carts expire on their own. A cart does not need transactions or joins, and treating a lost cart as a minor annoyance rather than a data-integrity event is the right call. The one correctness question is the merge: a shopper adds items as a guest under a temporary session id, then signs in and already had items saved from last week. The clean answer is to union the two carts by SKU, summing quantities and capping at available stock, then delete the guest cart. Read-your-writes matters here too. Route a customer's cart reads to the same node or use a store that gives per-key consistency. Otherwise the item they just added can appear to vanish on the next screen.

Prices and availability on cart lines are shown live from the catalog rather than frozen. A cart that has sat for a week reflects today's price and today's stock, and nothing is promised until checkout runs the atomic decrement. Saying that keeps the cart honest and defers every hard guarantee to the one path built to handle it.

What is expected at each level

Chewy scopes this round by level, and how far you carry the inventory and Autoship pieces is roughly what sorts the levels. Chewy's own careers page says round count and format vary by team, scope, and level, so treat the split below as a guide, not a contract.

SWE I

This level leans on breadth, roughly 80/20, and reports describe the round here as minimal, sometimes a single lighter session. Reach a working skeleton: the cart, order, and inventory services, sensible schemas with named keys, the checkout flow, and the atomic conditional decrement that prevents overselling. Above all, land that decrement correctly and do not over-build the rest. The bar: a clean, right-sized design with schemas and endpoints you can defend, and a correct answer for the last-unit race.

SWE II

Now depth enters, roughly 60/40. You should reach the reservation-with-TTL extension of the inventory answer without being pushed there. Design order placement as idempotent from the start instead of patching it later, and treat Autoship as a real component with exactly-once firing. You should be able to say why Postgres and not a sharded store, and why the cart lives somewhere else. The bar: you find the reservation and idempotency concerns yourself and defend the reasoning behind each.

Senior and above

Depth leads, roughly 40/60, and the scope widens past the happy path. Expect to reason about the reserve-charge-write sequence as a saga with clean compensation. Treat the Autoship edge cases (out of stock, price change, expired payment) as first-class policy. Plan degradation when the payment processor or a fulfillment center is down, and explain how inventory correctness would hold if you ever had to split stock across regions. Senior loops also draw the occasional generic prompt (a "design Twitter" or "car parking" style question), so be ready to apply the same requirements-first discipline to an unfamiliar shape. The bar: you own the correctness argument end to end and the interviewer redirects you rather than rescues you.