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.
Next JS
CDN
Redis
Database (MySQL, postgres or SQL)
Search database
Headless CMS
File storage like S3 or firestore
Static Generation (SSG): Home, marketing pages, legal change rarely, perfect to bake at build time and cache forever.
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.
ISR with on‑demand revalidation: Inventory and prices can change frequently. On‑demand revalidation (via revalidateTag) keeps pages up‑to‑date without wasting rebuilds.
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.
Edge or Node.js functions with cache‑control: Some API routes (pricing, inventory) can be cached with short TTLs
Browser cache
CDN / Edge cache
Next.js Full Route Cache
Next.js Data Cache
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
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.
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.
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.
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.
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.
Queue writes: Orders/inventory updates should use queues.
Rate limiting: Protect checkout APIs.
Separate read/write databases Read replicas for catalog traffic.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
