Design a E-commerce frontend

01Concrete scale assumptions

02Architecture decisions and rationale

03Client contracts and data boundaries

1type CartCommand = { mutationId: string; cartVersion: number;2  type: 'setQuantity'; productId: string; quantity: number; };3type CartResponse = { cartVersion: number; lines: CartLine[];4  totals: Money; warnings: { productId: string; message: string }[]; };

04Failure-mode analysis

05Observability and operations

• Measure product LCP/INP, search latency, cart mutation failures, checkout step drop-off, payment outcomes, and duplicate-prevention hits.
• Correlate one checkout attempt id across frontend, order, inventory, and payment services.
• Synthetic tests exercise browse-to-order in every supported region and payment mode.
• Feature flags and canaries isolate new checkout, promotion, and rendering behavior.

06Security and accessibility boundaries

• Authorize cart and order access server-side; validate every price, promotion, stock, and address rule again.
• Use provider-hosted or tokenized payment fields and prevent sensitive data entering analytics.
• Forms have correct labels, autocomplete, errors, focus recovery, and a complete keyboard path.
• Product images have useful alternatives, while inventory and price changes are announced without surprise.

ANSOne full answer, start to finish

Drive the discussion yourself first. This is one strong answer delivered the way you would say it in the room — a model, not the only correct design.

A storefront answer should be organized by the shopper's journey — browse, cart, checkout — because each stage has a different rule. Browsing is public and cacheable; the cart is fast and forgiving; checkout is about money and must be exactly right. Keep saying which stage you are in and what that stage's constraint is.

1. Step 1 · Clarify

   Ask: 'How big is the catalog? Do we need SEO on product pages? Guest checkout or accounts? One payment provider or several? And roughly what traffic, especially at sale peaks?' Assumptions: 'Large catalog, SEO matters, guest checkout allowed, one payment provider to start, and traffic that spikes hard during promotions.' The SEO and peak answers drive the rendering and caching decisions.

2. Step 2 · Requirements by stage

   Browse: fast first paint and good SEO on listing and product pages. Cart: add, remove, change quantity, and have it feel instant and survive a refresh. Checkout: collect address and payment, never double-charge, and confirm only when the order is really placed. Say the constraint per stage out loud: 'browse is cacheable and public, cart is optimistic and reversible, checkout is authoritative and idempotent.'

3. Step 3 · Rendering and the browse boxes

   'Listing and product pages are server-rendered or statically generated and revalidated, so the first paint is fast and crawlers see real content, then they hydrate into an interactive client. Behind that sits a catalog and search service that can be cached hard at the CDN and scaled separately from anything to do with checkout.'

4. Step 4 · The cart

   'The client treats the cart as the source of truth for display and does optimistic updates — add to cart shows immediately — while firing a request to persist it server-side. If that request fails, the optimistic change reverts and an error shows. The cart is reversible, so being wrong for a second is fine.'

5. Step 5 · Checkout: the part that must be exactly right

   'Checkout is a guarded multi-step flow — editing, validating, authorizing payment, confirming — backed by idempotent server endpoints. The order request carries an idempotency key generated once per attempt, so a network retry cannot create two orders. Inventory is checked authoritatively at submission time regardless of what the product page showed, because that display might be minutes stale. And I never show order confirmed optimistically — that waits for the server.'

6. Step 6 · Payment and data safety

   'Card fields are hosted by the payment provider or tokenized, so raw card data never touches my servers or my analytics. Cart and order access is authorized server-side; a guessable order id is not permission.'

7. Step 7 · Scale and what to measure

   'The catalog and media path scales independently at the CDN and absorbs the promotion spike; the checkout path is lower volume and stays private. After launch I would watch conversion alongside the technical causes — Core Web Vitals on product pages, API error rates, payment decline categories, and how often the idempotency guard actually fires.'

QAInterview questions and model answers