Interview Perspective

Strong answer direction: clarify early, since a marketplace introduces the Offer/seller layer on top of Product/SKU, and affects pricing, inventory pooling and fulfillment ownership. What interviewer is testing: whether you scope an intentionally huge problem down before designing anything.

• Does one SKU ever have multiple sellers? — If so, each seller's stock and price is a separate Offer against the same SKU -- see Architecture Deep Dive -> Product, SKU & Offer Model.

Strong answer direction: Product carries stable descriptive identity; SKU is the actual purchasable unit that inventory and price attach to. Collapsing them breaks the moment a product has variants (color, size). What interviewer is testing: whether the data model is precise enough to support inventory and pricing correctly later. Read deeper: Product, SKU & Offer Model.

• Where does price live? — On the Offer, tied to a SKU (and seller, in a marketplace) -- not on the descriptive Product record.

Strong answer direction: catalog reads are heavy and product metadata changes rarely, so cache-aside with a DB fallback is a strong default. What's safe to cache is display data; the checkout price and reservation decision are never served from that cache. What interviewer is testing: precise boundaries, not just 'cache things.' Read deeper: Catalog Read Path.

• What's a realistic cache hit rate? — It depends on catalog size, popularity skew, TTL and personalization -- treat any specific number as illustrative, not a guarantee.

Strong answer direction: without protection, a cache stampede sends many simultaneous misses to the DB at once. Request coalescing/single-flight and TTL jitter prevent this. What interviewer is testing: awareness of a specific, well-known cache failure mode beyond basic cache-aside. Read deeper: Failure & Scale -> Catalog Cache Stampede.

Strong answer direction: a relational DB can provide basic full-text search adequate at small scale; a dedicated search engine adds relevance ranking, faceting, typo tolerance, autocomplete and independent scaling as the catalog and traffic grow. What interviewer is testing: whether 'you always need Elasticsearch' is stated as an absolute or a scale-justified choice. Read deeper: Trade-offs -> Catalog Database vs. Search Index.

• What if the index is stale? — Discovery data only -- checkout always revalidates price and availability regardless of what search displayed.

Strong answer direction: they can be, for display/ranking purposes, but they're discovery data -- never checkout authority. Checkout always resolves current price and availability from the authoritative pricing/inventory path. What interviewer is testing: whether 'the index has a price field' is confused with 'the index is where checkout gets its price.'

Strong answer direction: reserve-at-checkout is the reasonable baseline for ordinary retail -- reserving on add-to-cart risks abandoned carts blocking popular inventory indefinitely. Extremely scarce, time-boxed inventory is a domain where earlier reservation is deliberately chosen instead. What interviewer is testing: whether 'reserve at checkout' is understood as a baseline for a reason, not dogma. Read deeper: Trade-offs -> Cart vs. Inventory Reservation.

• What does the cart actually store? — SKU/variant identity, quantity, and commonly a displayed-price snapshot for UX -- never authoritative for the final charge.

Strong answer direction: an atomic conditional reservation -- UPDATE ... WHERE available >= qty -- ensures exactly one of the two requests succeeds; the loser gets an informative 'no longer available' response. The reservation itself needs a durable identity (reservation_id, checkout/order id, sku, quantity, state, expiry), not just a decremented counter. What interviewer is testing: this is the single most important correctness question in the whole design. Read deeper: Inventory Reservation.

• Is a conditional SQL update the only way to implement this? — No -- optimistic versioning, row locks, and serialized per-SKU processing are all valid, chosen based on contention level.

Strong answer direction: the reserve operation must be idempotent -- a retry carrying the same checkout/reservation identity finds the existing ACTIVE reservation rather than creating a second one. What interviewer is testing: whether idempotency is applied consistently across the whole checkout path, not just at the API's outer edge.

Strong answer direction: a durable, recoverable expiry mechanism -- a scheduled scan, a delayed queue message, an expiry index, or a workflow timer -- not just a cache TTL notification, which can't be relied on as the sole correctness mechanism. What interviewer is testing: whether 'TTL' is understood as needing a durable enforcement mechanism behind it. Read deeper: Reservation Expiry.

• What if commit and expiry race at nearly the same instant? — A conditional/versioned transition ensures only one of the two wins -- see Failure & Scale -> Reservation Expiry Race.

Strong answer direction: it's the baseline invariant this design teaches, but some businesses intentionally support backorders/preorders. The invariant that generalizes: reservations must never allocate beyond what the SKU's own inventory policy permits, whatever that policy is. What interviewer is testing: whether absolute claims are qualified against real product variation.

Strong answer direction: inventory becomes a per-SKU-per-location record; checkout may need to choose a fulfilling location, and availability shown pre-checkout can remain approximate across locations. What interviewer is testing: whether multi-location is treated as a bounded extension rather than either ignored or over-built into a full warehouse-management design.

Strong answer direction: inventory, order, and payment are different systems (and payment is external), so no shared database transaction can span all of them. The saga pattern coordinates local commits with compensating actions instead. What interviewer is testing: whether the distributed-transaction problem is named precisely, not hand-waved as 'we'll use a transaction.' Read deeper: Checkout Orchestration.

Strong answer direction: create/reuse a durable pending checkout-order identity before the payment attempt -- this gives crash recovery a stable anchor. Creating the order only after payment succeeds trades away that recoverability for slightly less bookkeeping. What interviewer is testing: whether the candidate has a clear, defensible answer rather than leaving the ordering ambiguous. Read deeper: Trade-offs -> Order-Before-Payment vs. Order-After-Payment.

Strong answer direction: a stable checkout idempotency key (client-generated or server-issued) maps to a durable uniqueness constraint; a stored request fingerprint detects a conflicting reuse of the same key. What interviewer is testing: whether idempotency is modeled as a durable database guarantee, not a client-side convention alone. Read deeper: Checkout Idempotency.

Strong answer direction: not immediately -- a timeout is ambiguous, not a definitive failure. The payment may have actually succeeded. Apply an explicit bounded policy: extend the reservation while payment resolves, or define a later-success recovery/refund path if it must expire first. What interviewer is testing: this is the single most commonly missed nuance in e-commerce checkout design. Read deeper: Failure & Scale -> Payment Unknown, Reservation Nearing Expiry.

• What if the reservation must expire before payment resolves? — The system needs a pre-defined later-success recovery/refund path, not an improvised one discovered after the fact.

Strong answer direction: every step is durably recorded before the next is triggered, so the orchestrator resumes from the last known state on restart, and every command (reserve, charge, confirm) is idempotent so re-issuing the current step is always safe. What interviewer is testing: whether recoverability is designed in, not assumed. Read deeper: Failure & Scale -> Checkout Orchestrator Crash.

Strong answer direction: a definitive failure triggers a compensating release of the reservation -- but compensation itself can fail (the release call can error out), so it's retried idempotently with reservation TTL as the ultimate backstop. What interviewer is testing: whether compensation is understood as its own fallible operation, not automatic rollback. Read deeper: Checkout Compensation.

Strong answer direction: reference the Payment System module for idempotency keys, provider timeout ambiguity, webhooks and reconciliation on the payment side -- this module's job is the checkout/order/inventory boundary around payment, not payment internals themselves. What interviewer is testing: whether scope discipline is maintained instead of re-deriving payment system design from scratch mid-interview.

Strong answer direction: a direct publish-after-commit call has a dual-write gap -- the process can crash between the DB commit and the publish. A transactional outbox closes it: the event is written as a durable row in the same transaction as the order state change, and a separate relay publishes it, retrying until acknowledged. What interviewer is testing: recognition of the DB-to-broker dual-write problem as a real correctness gap. Read deeper: Transactional Outbox.

• Can the outbox relay itself create a duplicate? — Yes -- if it crashes between publishing and marking the row published, it can republish on restart. Consumers must be idempotent regardless.

Strong answer direction: it must not create a duplicate shipment -- a stable business idempotency key (order_id + fulfillment_operation) lets the consumer recognize and no-op the duplicate. What interviewer is testing: whether idempotency is understood as a requirement on every consumer, not just the producer. Read deeper: Event Consumer Idempotency.

Strong answer direction: no -- orders remain confirmed and paid, new orders continue to be accepted, and the outbox/broker retains fulfillment work durably until the outage resolves. If the outage risks breaching fulfillment SLOs, communicate delay proactively rather than silently. What interviewer is testing: whether async decoupling is actually understood, not just drawn as a queue in the diagram.

Strong answer direction: the bottleneck is one storage row/partition for that one SKU, not compute capacity -- every reservation attempt contends on the same row regardless of how many stateless API instances are running. Mitigations include bounded/backoff retry, admission control or a waiting room, and serialized per-SKU processing for extreme contention. What interviewer is testing: whether 'just autoscale' is recognized as insufficient for a storage-level hot key. Read deeper: Flash-Sale Hot-SKU Contention.

• Does partitioning inventory by SKU help here? — It isolates different SKUs from each other, but it cannot split one indivisible hot SKU without additional design like sub-partitioning the count or a preallocation scheme.

Strong answer direction: fail fast once inventory is exhausted, before the checkout flow reaches the payment step -- this stops doomed checkout attempts from generating unnecessary provider traffic. What interviewer is testing: whether the candidate connects inventory state to upstream traffic shaping, not just downstream error handling.

Strong answer direction: catalog display, search results, recommendations, analytics, and order-history display can all be eventually consistent. The reservation grant, order-state transitions, and payment identity need guarded, authoritative decisions at the moment they're made. What interviewer is testing: whether 'consistency' is answered with concrete invariants rather than a single blanket label. Read deeper: Trade-offs -> Consistency by Workload.

Strong answer direction: a read-only order-status display view can be cached with explicit staleness semantics -- the underlying order-state transition itself must still go through a guarded write, not a cache write.

Strong answer direction: the client retries with the same checkout idempotency key, and the durable checkout/reservation identity resolves the retry to the existing reservation rather than creating a second one -- this is exactly the case checkout idempotency is designed to make a non-event. Read deeper: Checkout Idempotency.

Strong answer direction: this is exactly the payment-unknown/reservation-expiry edge case -- the system needs a pre-defined policy (extend, or a later-success recovery/refund path) rather than an improvised response. Read deeper: Failure & Scale -> Payment Unknown, Reservation Nearing Expiry.

Strong answer direction: outbox-lag monitoring surfaces this; the order is still safely CONFIRMED, and fulfillment simply starts ten minutes later than usual once the relay catches up -- not a correctness issue, an operational lag to watch.

Strong answer direction: no problem -- search is discovery data, not checkout authority. Checkout revalidates current availability regardless of what the (possibly stale) search result showed, and the shopper sees an accurate 'no longer available' message at that point.

Strong answer direction: every reconciliation repair uses a stable, idempotent reconciliation/action identity, so a re-run recognizes already-applied repairs as no-ops instead of double-applying them (e.g. double-crediting a refund or re-confirming an already-confirmed order). Read deeper: Order Reconciliation.

Strong answer direction: a conditional check against the fulfillment state at the moment of processing (not the state the customer saw when clicking cancel) decides whether cancellation is still valid -- if not, route to the return/refund-after-shipment path instead. Read deeper: Failure & Scale -> Cancellation Races with Shipping.