FSD Frontend System Design

Part VI — The Blueprint · Lesson 11.3

HLD – E-commerce App (Amazon, Flipkart)

In one lineDifferent pages need different rendering strategies — that decision is the whole design.

Where you've seen itA product page indexed by Google in seconds, and a cart that's wrong the moment it's served from a cache.

  • Time20 min
  • DiagramPer-route rendering split + the cart consistency problem
  • Chapter11 · High Level Design

Diagram

diagram
1–2 · SCOPE AND SCALE

  in scope   home · category · search · product · cart · checkout
  out        seller portal · reviews moderation · logistics
  scale      100M products · 10M DAU · huge SEO dependency
             traffic spikes 20× on sale days
diagram
3 · THE RENDERING SPLIT — the core answer

  route            strategy        why
  ─────────────────────────────────────────────────────────────
  /                ISR (5.6)       same for everyone, changes daily
  /category/:id    ISR + edge      SEO critical, cacheable
  /product/:id     ISR + client    SEO critical; price & stock
                   island for      are fetched client-side so the
                   price/stock     page itself stays cacheable
  /search?q=       SSR             per-query, must be fresh
  /cart            CSR             per-user, never cached
  /checkout        CSR             per-user, no-store (6.7)

  One app, five strategies. Saying "SSR everything" misses the point.
diagram
4 · ARCHITECTURE

  ┌────────┐        ┌─────────┐        ┌──────────────────┐
  │ Client │───────►│   CDN   │───────►│  BFF / edge SSR  │
  └────┬───┘        └─────────┘        └────────┬─────────┘
       │  price/stock, cart, checkout            │
       └─────────────────────────────────────────┤
                                                 ▼
                            catalog · pricing · inventory · cart · order
diagram
6a · DEEP DIVE — CART CONSISTENCY

  guest cart          localStorage (6.2)  ← survives, no login needed
      │ user logs in
      ▼
  MERGE with server cart   ← the interesting case
      conflict rules: union of items · quantities max()
                      · re-validate every price and stock
      ▼
  server cart = source of truth from here on

  Optimistic add-to-cart with rollback (6.9), because a spinner on
  "Add to cart" measurably costs conversions (5.2).
diagram
6b · DEEP DIVE — PRICE AND STOCK FRESHNESS

  problem  the page is cached for SEO, but price must be current

  solve    render page shell + product copy from cache (fast LCP)
           fetch /api/price-stock?ids=… on mount     (always fresh)
           re-validate ONCE MORE at checkout          (authoritative)

  Never trust a cached price at payment time — always re-check
  server-side before charging (3.5).

How it works

  1. Split by route — SEO pages static or ISR at the edge, per-user pages client-rendered.
  2. Islands for dynamic bits so a cacheable page can still show live price and stock.
  3. Cart starts local for guests, merges on login, and becomes server-owned after that.
  4. Checkout is no-store, network-only, with idempotency keys on the order request (1.5).
  5. Search is SSR with cursor pagination and faceted filters kept in the URL (6.10).

Trade-offs

ChoiceCost
ISR for product pagesStale copy text until revalidation
Client-fetched priceAn extra request; brief price skeleton
Guest cart in localStorageMerge complexity at login
Optimistic add-to-cartRollback UI when stock runs out

Interview angle

"Why not just SSR the whole site?"

  • Product and category pages are identical for everyone — rendering them per request wastes capacity that matters on sale days.
  • ISR at the edge gives the same SEO and a better LCP, with a client island keeping price and stock accurate.
  • Cart and checkout are per-user and must never be cached, so those stay client-rendered with no-store.

Recap

  • The design is the per-route rendering decision.
  • Cache the page, fetch the price — islands keep SEO and accuracy together.
  • Guest cart merges on login; the server owns it afterwards.