Micro-Frontends with Next.js Multi-Zones

The 30-Second Interview Answer

Next.js Multi-Zones is an enterprise architecture pattern that merges multiple independently built and deployed Next.js applications into a single unified domain using HTTP rewrites. For example, a team can deploy the marketing app from one repository, the e-commerce store from another, and the customer dashboard from a third, while users browse them seamlessly under one origin.

Learning Objectives

Architect micro-frontends using Next.js Multi-Zones and assetPrefix.

Configure rewrites in next.config.js to route subpaths to independent upstream deployments.

Prevent static asset collisions using customized basePath and assetPrefix configurations.

Share global headers, navigation states, and authentication across independent zones.

Prerequisites & Background Knowledge

Micro-frontends principlesHTTP reverse proxyingWebpack/Turbopack asset prefixes

Why Interviewers Care

Essential for staff/principal frontend architect interviews at Fortune 500 enterprises with hundreds of developers across autonomous squads.

The Challenge

Explain how Next.js Multi-Zones enables micro-frontends across independent repositories. Configure next.config.js for both the host marketing app and an upstream blog zone with dedicated assetPrefix.

Code Architecture & Implementation

1// apps/main-site/next.config.js (HOST APPLICATION)
2const BLOG_ZONE_URL = process.env.BLOG_ZONE_URL || 'https://blog-zone.internal.net';
3
4module.exports = {
5  async rewrites() {
6    return [
7      // 1. Route blog pages to the independent blog zone deployment
8      {
9        source: '/blog',
10        destination: `${BLOG_ZONE_URL}/blog`,
11      },
12      {
13        source: '/blog/:path*',
14        destination: `${BLOG_ZONE_URL}/blog/:path*`,
15      },
16      // 2. Route static assets generated by the blog zone
17      {
18        source: '/blog-static/_next/:path*',
19        destination: `${BLOG_ZONE_URL}/_next/:path*`,
20      },
21    ];
22  },
23};

Architectural Explanation

Multi-Zones splits a massive monolithic application into autonomous deployable units. Each engineering squad owns their repository, CI/CD pipeline, and deployment cadence. The host application (often marketing or API gateway) defines rewrites that transparently forward requests matching /blog/* to the blog server. By configuring basePath: "/blog" and a unique assetPrefix: "/blog-static", both apps coexist harmoniously on example.com without build bottlenecks.

Common Mistakes & Anti-Patterns

Forgetting to rewrite `_next/static` assets for the secondary zone, causing CSS and JS bundles to 404.

Attempting client-side `router.push()` between zones expecting SPA transitions (cross-zone navigations must use regular `<a>` tags or native browser redirects).

Using Module Federation instead of Multi-Zones without realizing its maintenance and version coupling overhead.

Interview Follow-Up Traps

The interviewer asks: "Can two zones share React state in memory?" No! Zones are separate web applications; they share state through cookies, localStorage, or server-side databases, not React Context.

Frequently Asked Questions

What is the primary benefit of Multi-Zones over a monolithic repo?

Independent deployment lifecycles: a broken deployment in the blog zone does not take down the checkout or marketing site, and CI build times stay fast.

How do you share design systems across Multi-Zones?

Publish shared UI component libraries to private npm or manage them in a Turborepo monorepo.

Can you combine App Router and Pages Router across zones?

Yes! Host can be on App Router while an upstream zone remains on Pages Router.

Multi-Tenant Architecture & Custom Subdomain Routing High-Scale E-Commerce Architecture (Vercel Commerce Pattern)