08 / 09

Design Next.js architecture for a high-traffic e-commerce platform?

Difficulty: 7/10
SSR/SSG, caching & edge, routing & API layer

To handle global, high‑traffic e‑commerce with Next.js, you need a hybrid rendering architecture that shifts as much work as possible to the edge, caches aggressively, and reserves dynamic server work only for what truly can’t be pre‑built. The goal is to serve most pages from a CDN cache near the user, while keeping content fresh and personalisation accurate.

We should start by auditing every route by its data freshness requirement and personalization level, then assign the cheapest rendering strategy that meets that requirement." Static for marketing, ISR with on-demand revalidation for catalog, SSR only for cart/checkout/account.

Here is the High level components
  1. 1

    Next JS

  2. 2

    CDN

  3. 3

    Redis

  4. 4

    Database (MySQL, postgres or SQL)

  5. 5

    Search database

  6. 6

    Headless CMS

  7. 7

    File storage like S3 or firestore

NextJS rendering strategies:
  1. 1

    Static Generation (SSG): Home, marketing pages, legal change rarely, perfect to bake at build time and cache forever.

  2. 2

    ISR + Edge caching: Product Listing (PLP) & search results Change moderately (new products, prices). ISR rebuilds the page in the background after a set interval or on‑demand. First request from a region still triggers a static file response from the CDN.

  3. 3

    ISR with on‑demand revalidation: Inventory and prices can change frequently. On‑demand revalidation (via revalidateTag) keeps pages up‑to‑date without wasting rebuilds.

  4. 4

    Dynamic (SSR / Client‑side): Fully user‑specific information such as Cart, Checkout, My Account. Must be server‑rendered (or client‑fetched) per request, never shared.

  5. 5

    Edge or Node.js functions with cache‑control: Some API routes (pricing, inventory) can be cached with short TTLs

Caching layer
  1. 1

    Browser cache

  2. 2

    CDN / Edge cache

  3. 3

    Next.js Full Route Cache

  4. 4

    Next.js Data Cache

  5. 5

    external cache (Redis)

Browser cache is controlled by Cache-Control headers. For static/ISR pages, set public, max-age=…, stale-while-revalidate=…. For dynamic pages, use private, no-store (cart/checkout). Use long cache durations for: images, fonts, JS chunks

CDN/Edge network, This is the first line of defence for global traffic. The CDN caches the full HTML response for ISR and SSG pages at locations worldwide.With stale-while-revalidate, a popular page is served from CDN while a single background rebuild happens – millions of users never touch your origin. CDN is configured via s-maxage and stale-while-revalidate in the Cache-Control header. Next.js automatically sets s-maxage equal to the ISR revalidate time. Caches HTML, Images, JS bundles, API responses where possible

Next.js Full Route Cache When a page is statically rendered (SSG/ISR), Next.js stores the HTML and RSC payload in its own server cache. On subsequent requests the cached page is returned instantly, unless it has expired or been purged. On‑demand revalidation (revalidateTag or revalidatePath) evicts this cache, causing the next request to rebuild the page.

Next.js Data Cache Behind every route, fetch calls are cached by Next.js (when using the App Router with cache: 'force-cache' or a next.revalidate option). This means even if a page is rebuilt, unchanged API calls (e.g. product descriptions) are served from the local data cache – your backend APIs aren’t hammered. You can tag fetched data (next.tags) and revalidate it precisely when a CMS webhook fires (e.g. product updated → revalidateTag('products')).

External cache like redis for session data, inventory counts that must be real‑time, and personalised fragments. Redis can serve as a fast lookup before hitting the main database. Use a managed Redis cluster with regional replicas. Critical for inventory, pricing, search results, recommendations

Data layer
  1. 1

    The biggest challenge is the database. If your master database is in one region, a user on the other side of the world will feel the latency.

  2. 2

    Read replicas in multiple regions. Next.js functions connect to the nearest replica for reads. Writes (checkout) may still hit the master – but you can mitigate with Redis queues or a distributed database.

  3. 3

    Globally distributed databases: PlanetScale, CockroachDB, AWS Aurora Global Database. They provide multi‑master or multi‑region read replicas with conflict resolution. Ideal for cart and checkout if you want zero‑downtime region failover.

  4. 4

    Cache the database: Use a Redis cluster with regional replicas for frequently‑accessed product data, even for dynamic routes. A product page that isn’t user‑specific can be assembled entirely from Redis, requiring no DB hit.

Optimsations:
  1. 1

    Image optimisation: Use Global image CDN with on‑the‑fly resizing, next/image with a global image CDN (like Vercel’s built‑in, or Cloudflare Images) ensures product photos are resized and served from the edge. Without a global image CDN, large images will cause poor performance for distant users.

  2. 2

    Queue writes: Orders/inventory updates should use queues.

  3. 3

    Rate limiting: Protect checkout APIs.

  4. 4

    Separate read/write databases Read replicas for catalog traffic.

Scenario Questions

0-2 years experience

  1. 1You need to add a new product detail page that must load in under two seconds for first‑time visitors. How would you structure the page using Next.js features?
  2. 2A user reports that the product list page sometimes shows stale prices after a price update. What could be causing that and how would you fix it?
  3. 3When a user clicks a Next.js Link from the home page to a product page, what happens under the hood in terms of data fetching and rendering?

2-5 years experience

  1. 1We want to run a flash‑sale where product pages are pre‑rendered but also need to reflect inventory changes in real time. Which Next.js rendering mode would you choose and why?
  2. 2During a load test, the API routes handling cart operations start timing out. Walk me through how you would debug the issue and what architectural changes you might consider.
  3. 3Explain the trade‑offs between Incremental Static Regeneration and Server‑Side Rendering for category pages that receive frequent updates.

5-8 years experience

  1. 1Design the end‑to‑end request flow for a checkout page that must be SEO‑friendly, highly available, and handle 50k concurrent users. Include Next.js rendering, edge caching, and backend services.
  2. 2How would you partition the Next.js application into separate services or bundles to reduce cold‑start latency for a global audience?
  3. 3Discuss how you would implement a multi‑region CDN strategy with Next.js to minimize latency while keeping data consistency for personalized recommendations.

8+ years experience

  1. 1Our legacy monolith serves product pages with server‑side templates. Outline a migration plan to a Next.js architecture that minimizes disruption and supports gradual rollout.
  2. 2At scale, how do you manage versioning and feature flagging across multiple Next.js deployments while ensuring backward compatibility for third‑party integrations?
  3. 3What governance and observability practices would you put in place to allow several teams to own different parts of the Next.js e‑commerce platform without causing architectural drift?

Follow-up Questions

  • How would you monitor page‑render latency across regions?
  • What changes would you make if traffic spikes tenfold during a flash sale?
  • How do you ensure SEO requirements are met for dynamically generated product pages?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.