Shopping | FineFrontend

System design interview question

Shopping

Design a reliable cart and checkout journey: guest cart merge, authoritative totals, shipping choices, secure payment handoff, and recovery when an order’s outcome is unknown.

Medium40 min interview

About 14 min read

Read any section, at your own pace

A shopping bag, checkout summary, and confirmed order with idempotent checkout flow. — The cart becomes a server-confirmed checkout quote and one recoverable purchase attempt.

The key idea

A purchase is a server-authorized workflow. A responsive cart can be optimistic, but totals, payment outcomes, and orders must be reconciled against authoritative state.

Question & requirements

Design the frontend for shopping from cart to confirmed order. People can add and edit items as guests, sign in without losing their cart, choose an address and delivery option, review final totals, and complete payment. This question focuses on transaction correctness; Ecommerce covers storefront discovery and product details. Explain state transitions and recovery, not a payment processor’s internal ledger.

Clarify	Assumption for this answer

Architecture & authority

Cart and checkout boundaries

Architecture

Cart / Checkout UI
    │ authenticated or guest session
Commerce API
    ├─ Cart service + version checks
    ├─ Quote service → price / stock / tax / delivery
    └─ Order + checkout-attempt service
             │ server credentials
       Hosted payment provider
             │ signed webhook events
       Order reconciliation worker
             │
       Durable order state → status API → UI

The frontend owns form drafts, immediate feedback, and displaying server state. The backend owns permitted quantities, promotions, tax, inventory reservations, order creation, and payment-session creation. The provider collects payment details in a hosted page and sends authenticated events. Workers reconcile events and durable order state even if the customer closes the browser.

Use an adapter around payment-provider URLs and outcome types so components do not assume one provider event name everywhere. Do not place secret keys in the browser. The app is still responsible for protecting addresses and order history, verifying ownership, and preventing a user from starting checkout for somebody else’s cart.

Entities & checkout state

Entity	Key fields	Invariant
Cart	id, owner/session, version, currency, line items	A line references a sellable SKU; server validates quantity.
Quote	id, cartVersion, address/delivery context, totals, expiresAt	Totals are one internally consistent server snapshot.
Attempt	id, quoteId, idempotencyKey, providerSessionId, status	Retries of the same intent resolve to the same attempt.
Order	id, owner, line snapshots, payment state, fulfillment state	Payment and fulfillment are separate lifecycle dimensions.

Illustrative checkout state union

TypeScript

type CheckoutState =
  | { kind: 'editing' }
  | { kind: 'quoting' }
  | { kind: 'ready'; quoteId: string; expiresAt: string }
  | { kind: 'starting'; attemptId: string }
  | { kind: 'payment'; attemptId: string }
  | { kind: 'unknown'; attemptId: string }
  | { kind: 'processing'; attemptId: string }
  | { kind: 'confirmed'; orderId: string }
  | { kind: 'failed'; attemptId: string; message: string };

Keep payment status and shipment status separate: paid does not mean delivered, and an accepted order may await a delayed payment. A unknown state means the client lacks an answer; it is not a synonym for server failure. This distinction determines which actions are safe to expose.

Cart edits & concurrency

Quantity controls should respond immediately, but track pending edits separately from the authoritative cart. Send absolute desired quantities with the observed cart version, not ambiguous increments that can be replayed accidentally. Serialize mutations per cart or coalesce rapid edits so only the latest desired quantity is sent after earlier work finishes. Do not let a slow response overwrite a more recent intent.

Illustrative cart mutation contract

HTTP

PATCH /api/carts/cart_8/items/shirt-blue-m
If-Match: "cart-v12"
Content-Type: application/json

{ "quantity": 3 }

200 → authoritative cart version 13
412 → version changed; refetch and reconcile user intent

On a version conflict, fetch the current cart and show meaningful adjustments. Reapplying an absolute quantity may be appropriate, but do not silently overwrite a different tab’s removal without a product decision. A tab-level broadcast can invalidate other tabs’ cart caches; it improves freshness without becoming the source of truth. Disabling checkout while edits are pending avoids quoting an older cart accidentally.

Guest cart persistence & sign-in merge

Keep an opaque guest-cart session in a secure cookie where practical; the server stores the cart. A local snapshot can improve startup but is not authoritative. On sign-in, call an explicit merge endpoint once per guest-cart identity. The server authorizes the destination account, validates SKUs and stock rules, and records that the guest cart was consumed so retries cannot add its quantities repeatedly.

Situation	Default merge policy
Same SKU in both carts	Combine quantities up to the allowed limit and report the adjustment.
Unavailable or deleted SKU	Preserve a visible unavailable line or explain removal; do not silently substitute.
Different currency or market	Ask the customer to resolve the market; do not add money from different currencies.
Merge request times out	Retry the same merge identity and fetch the destination cart; do not create a second merge.
Sign-out or account switch	Clear private cart and checkout caches and detach guest state deliberately.

Guest persistence is a convenience with limits. A shared device should not reveal a prior customer’s address or payment history. Tell the user when merging changes quantities or promotions, and keep that message visible until they have a chance to review the result.

Idempotency & hosted payment

Create one client-generated operation ID for a checkout intent and retain it across timeout retries. The server binds that key to the user or guest session and an immutable request fingerprint, stores a durable result, and rejects key reuse with different parameters. Concurrent identical submissions must resolve to one attempt. The provider’s idempotency mechanism is an additional boundary, not a replacement for the application’s order deduplication.

Different retry keys can still represent the same purchase

Two tabs can generate different operation IDs for the same cart version and quote. Enforce a server-side single-active-attempt policy and a uniqueness or transactional locking boundary for the purchase intent, then reuse the active attempt or return a conflict. Scope it to the authorized cart and accepted quote; deliberately starting a new purchase after a terminal outcome requires an explicit transition. Per-key deduplication alone cannot prevent two independent keys from creating duplicate orders.

Illustrative start-payment request

JSON

{
  "operationId": "b7b94d94-81ce-47f5-b09e-aa7b5d0e8d25",
  "quoteId": "quote_24",
  "cartVersion": 13,
  "returnPath": "/orders/status"
}

The backend validates quote ownership, expiry, stock, and totals, then creates a provider session with server credentials and returns a vetted payment URL. Prefer the provider’s supported hosted integration rather than collecting card numbers in app form state. Do not pass arbitrary customer-provided redirect URLs to the provider. Payment methods can require authentication or complete later, so the resulting state model must represent those outcomes.

A double-click should be prevented in the UI, but correctness must survive two browser tabs, a reload, and duplicated requests. Generate a new operation ID only for a deliberate new intent after the previous attempt’s state is known.

Cart	Guest and signed-in carts; multiple tabs possible	Server cart versions and explicit merge are necessary.
Checkout	Physical goods in one currency per order	Address, delivery, inventory, and tax can change the quote.
Payment	Hosted provider checkout; delayed outcomes possible	The browser return is not proof of payment.
Inventory	Validated at checkout; optional short reservation	Adding to cart does not guarantee stock.
Excluded initially	Subscriptions, split tenders, recurring orders	Keep one understandable purchase workflow.

Shopping

Question & requirements

The purchase journey

Build a cart

Identify and deliver

Review

Start payment

Reconcile

Architecture & authority

Cart and checkout boundaries

Entities & checkout state

Illustrative checkout state union

Cart edits & concurrency

Illustrative cart mutation contract

Guest cart persistence & sign-in merge

Money, delivery & quote freshness

Fresh totals do not imply permanent stock

Idempotency & hosted payment

Different retry keys can still represent the same purchase

Illustrative start-payment request

Unknown outcomes & order recovery

Return from payment

Reconcile evidence

Show pending honestly

Recover after closing

Forms, accessibility & privacy

Tests & operational signals

A 40-minute interview answer

0–5 minutes

5–13 minutes

13–24 minutes

24–34 minutes

34–40 minutes

Sources & further reading

01Question & requirements

02The purchase journey

Build a cart

Identify and deliver

Review

Start payment

Reconcile

03Architecture & authority

Cart and checkout boundaries

04Entities & checkout state

Illustrative checkout state union

05Cart edits & concurrency

Illustrative cart mutation contract

06Guest cart persistence & sign-in merge

07Money, delivery & quote freshness

Fresh totals do not imply permanent stock

08Idempotency & hosted payment

Different retry keys can still represent the same purchase

Illustrative start-payment request

09Unknown outcomes & order recovery

Return from payment

Reconcile evidence

Show pending honestly

Recover after closing

10Forms, accessibility & privacy

11Tests & operational signals

12A 40-minute interview answer

0–5 minutes

5–13 minutes

13–24 minutes

24–34 minutes

34–40 minutes

Sources & further reading

Question & requirements

The purchase journey

Architecture & authority

Entities & checkout state

Cart edits & concurrency

Guest cart persistence & sign-in merge

Money, delivery & quote freshness

Idempotency & hosted payment

Unknown outcomes & order recovery

Forms, accessibility & privacy

Tests & operational signals

A 40-minute interview answer