Ecommerce | FineFrontend

System design interview question

Ecommerce

Design a fast, discoverable storefront with shareable search, product variants, reliable availability, and a clear separation between catalog content and customer-specific data.

Medium35 min interview

About 13 min read

Read any section, at your own pace

Discovery state lives in the URL, while product records and price availability come from the catalog service.

The key idea

A storefront must help people discover the right product quickly while making clear which information is cached and which purchase decisions require fresh server authority.

Question & requirements

Design the frontend of an ecommerce storefront. Visitors browse categories, search and filter products, inspect a product and its variants, and add an available variant to a cart. Explain pages, rendering, state ownership, API contracts, caching, and responsive behavior. The focus here is discovery and product details; the separate Shopping question covers cart reconciliation, checkout, and payment correctness.

Clarify	Assumption for this answer

Routes & discovery

Use public routes for the homepage, category listing, search results, and product details. A route like /products/linen-shirt is a durable product identity; a sku query parameter can restore the selected variant. Category, query, sort, selected facets, and pagination belong in the URL so sharing, refresh, and browser Back reconstruct the same result. The server validates parameters and supplies a canonical normalized form.

Illustrative shareable browsing URLs

Routes

/categories/shirts?color=blue&size=m&sort=price-asc&page=2
/search?q=linen&category=shirts
/products/linen-shirt?sku=shirt-blue-m

Changing a facet resets the pagination position. On mobile, a filter sheet can hold an unapplied draft; Apply updates the URL once, while Cancel discards that draft. Desktop checkboxes may commit immediately. Browser navigation must restore committed filters and scroll position rather than keeping stale local controls. Preserve a result snapshot while loading a replacement, but label it as updating and prevent an old request from replacing newer filters.

Architecture & boundaries

Catalog discovery architecture

Architecture

Browser
  Route / URL controller
    ├─ Category + search grid
    ├─ Product gallery + variant selector
    └─ Cart handoff
            │
      Storefront API / BFF
       ├─ Catalog + search index
       ├─ Market price service
       └─ Availability service

Public HTML + product media → CDN
Account/cart data → authenticated private responses

A backend-for-frontend can assemble one page-shaped response from catalog, pricing, and inventory systems, reducing browser waterfalls. It does not replace authorization or the authoritative pricing service. Separate server-rendered content from small interactive islands such as filters, gallery controls, and variant selection. Recommendations and review widgets can load after the useful product information rather than delaying it.

Feature modules own search, product details, and cart integration; shared components own visual primitives. The data adapter validates incoming payloads and maps transport errors into typed outcomes. Keep search ranking, promotions, and availability policies on the server so the browser cannot accidentally create competing business rules.

Data model & ownership

Entity	Important fields	Ownership
Product	id, slug, title, description, media, categoryIds, variantIds	Catalog service; descriptive content may be cached.
Variant	sku, attribute values, image references	Stable sellable identity used by the cart.
Offer	sku, market, currency, minor-unit amount, priceVersion	Pricing service; never trusted from submitted browser values.
Availability	sku, region, status, checkedAt	Inventory service; an observation, not a reservation.
Search page	queryKey, ordered productIds, facets, nextCursor	Server search result scoped to exact browsing context.

Normalize reusable product summaries by product ID and preserve the server’s ordered list separately. A category response can provide card data directly; fetching every card individually would create a waterfall. Keep selected thumbnail, filter-sheet draft, and hover state local. Keep market and locale explicit rather than inferring them independently in multiple components.

Do not combine all state into one global store. The URL owns committed discovery state, the query cache owns remote snapshots, and the product page owns temporary presentation. Cart mutation state belongs to the cart boundary. Stable IDs connect these parts without duplicating entire product objects into every state container.

Search & product contracts

Illustrative product response, not a live application API

JSON

{
  "product": {
    "id": "p_42",
    "slug": "linen-shirt",
    "title": "Linen shirt"
  },
  "variants": [
    {
      "sku": "shirt-blue-m",
      "attributes": {
        "color": "blue",
        "size": "m"
      },
      "offer": {
        "currency": "USD",
        "amountMinor": 4500,
        "version": "price_18"
      },
      "availability": {
        "status": "in-stock",
        "checkedAt": "2026-10-03T08:00:00Z"
      }
    }
  ],
  "market": "US"
}

GET /api/catalog/search accepts a validated query, selected facets, sort, market, and cursor or page. Return bounded results plus facet counts, the applied filters, and pagination metadata. Clarify whether counts reflect all selected filters or exclude the facet currently being edited. An opaque cursor ties to a query fingerprint; using it after filters change must fail clearly or restart from the first page.

GET /api/catalog/products/:slug returns descriptive content plus a market-specific offer snapshot. Distinguish missing products, unsupported markets, temporary offer failures, and unavailable variants. If the pricing dependency is down, a usable description may remain visible while purchase actions are disabled with an explanation. Never invent a zero price as a fallback.

Caching & freshness

Data	Suggested policy	Correctness boundary
Product descriptions and media	Public cache with versioned assets and targeted invalidation	Changes appear after the chosen freshness window.
Search result snapshots	Bounded cache keyed by normalized query, market, locale, and facets	Never reuse a page under a different filter context.
Price and availability	Shorter freshness; revalidate before a purchase action	Cached display does not authorize a sale.
Cart and account	Private, user-scoped cache cleared on identity change	No cross-user leakage through CDN or query keys.

Use stale content deliberately. A description can remain visible during a refresh; a stale availability label should show that it is checking. Request coalescing avoids duplicate loads for the same context. Bound caches by count or memory and expire old search snapshots. A promotion update can invalidate product and listing offers without evicting immutable photographs.

Cache-Control private prevents shared caching but does not prohibit a browser cache; no-store expresses a different intent. Pick directives for each response class rather than applying a single global value. Do not include authenticated personalization in a public response just because most of its product fields are public.

Catalog	One retailer, physical products, multiple variants	A product groups distinct sellable SKUs.
Identity	Browsing is public; cart can be guest-owned	Public catalog HTML must not contain private account data.
Market	One selected region and currency per browsing session	Prices, availability, and cache keys include market context.
Scale	Large catalog with bounded result pages	Filtering and search run on the server.
Excluded initially	Marketplace sellers, subscriptions, live auctions	Keep the purchase path understandable before adding domains.

Ecommerce

Question & requirements

Routes & discovery

Illustrative shareable browsing URLs

Architecture & boundaries

Catalog discovery architecture

Data model & ownership

Search & product contracts

Illustrative product response, not a live application API

Rendering & SEO

Variant selection & purchase readiness

Select

Refresh offer

Confirm readiness

Add exact SKU

Caching & freshness

Performance & responsive behavior

Accessibility, trust & privacy

Failures, tests & observability

A 35-minute interview answer

0–5 minutes

5–12 minutes

12–22 minutes

22–30 minutes

30–35 minutes

Sources & further reading

01Question & requirements

02Routes & discovery

Illustrative shareable browsing URLs

03Architecture & boundaries

Catalog discovery architecture

04Data model & ownership

05Search & product contracts

Illustrative product response, not a live application API

06Rendering & SEO

07Variant selection & purchase readiness

Select

Refresh offer

Confirm readiness

Add exact SKU

08Caching & freshness

09Performance & responsive behavior

10Accessibility, trust & privacy

11Failures, tests & observability

12A 35-minute interview answer

0–5 minutes

5–12 minutes

12–22 minutes

22–30 minutes

30–35 minutes

Sources & further reading

Question & requirements

Routes & discovery

Architecture & boundaries

Data model & ownership

Search & product contracts

Rendering & SEO

Variant selection & purchase readiness

Caching & freshness

Performance & responsive behavior

Accessibility, trust & privacy

Failures, tests & observability

A 35-minute interview answer