What are Multi-Zones in Next.js and when would you split an app into zones?

Q: What are Multi-Zones in Next.js and when would you split an app into zones?

**Target Audience:** Senior frontend and platform engineers preparing for architecture interviews — assumes App Router routing, rewrites and deployment basics. **Difficulty:** Hard > **How to read this doc:** Each idea is explained in plain language first, then tagged with `📌 Interview term:`. Every behaviour claim was checked against the Next.js 16.4.2 Multi-Zones guide shipped with the package and, in the **Verified** section, against two real 16.4.2 apps (a home zone and a blog zone) running side by side, tested with `curl` and a real Chromium browser. ## 1. Why This Even Matters — A Story First A big museum outgrows one building. Instead of one giant hall where every renovation closes the whole museum, it opens separate wings: the modern art wing, the history wing, the main hall. Each wing has its own staff, its own opening schedule and its own renovations. Visitors still enter through one front door and see one museum name, and a corridor sign tells them where each wing is. W

The problem

Question presented to candidate: "Our Next.js monolith takes 25 minutes to build and three teams keep blocking each other's releases. Someone proposed Multi-Zones. What are they, how do they work, and would you recommend them here?"

What a strong answer should cover:

A zone is a separate Next.js app serving a set of paths on the same domain (for example /blog/*); a default zone serves everything else.
Routing by rewrites in the default app's next.config (or any HTTP proxy, or proxy.ts for dynamic decisions), and assetPrefix on each non-default zone so /_next assets do not collide.
Navigation inside a zone is soft; crossing zones is a hard navigation, so links across zones should be plain <a> tags and pages used together should share a zone.
Benefits: independent builds and deploys, smaller apps, team autonomy, even different frameworks. Costs: full reloads between zones, duplicated framework JavaScript, shared layout and design system drift, cross-zone Server Action origins, coordinated releases via feature flags.
Alternatives to consider first: route groups and code ownership in one app, monorepo build caching, or splitting only truly separate sections.

Clarifying questions expected:

"How often do users move between the sections we would split?" — frequent crossings make zones feel slow.
"Is the pain build time, deploy coupling, or team ownership?" — some of those have cheaper fixes.

Code / implementation expected: Yes — the rewrites in the default zone and the assetPrefix in the other zone.

nextjs
multi-zones
micro-frontends
architecture

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Senior frontend and platform engineers preparing for architecture interviews — assumes App Router routing, rewrites and deployment basics. Difficulty: Hard

How to read this doc: Each idea is explained in plain language first, then tagged with 📌 Interview term:. Every behaviour claim was checked against the Next.js 16.4.2 Multi-Zones guide shipped with the package and, in the Verified section, against two real 16.4.2 apps (a home zone and a blog zone) running side by side, tested with curl and a real Chromium browser.

1. Why This Even Matters — A Story First

A big museum outgrows one building. Instead of one giant hall where every renovation closes the whole museum, it opens separate wings: the modern art wing, the history wing, the main hall. Each wing has its own staff, its own opening schedule and its own renovations. Visitors still enter t

The solution is hidden so you can try first

10 min read · 9 sections

Read the code

Home zone next.config.ts: rewrite the blog paths to the blog zone

// home zone: next.config.ts
import type { NextConfig } from "next";
const BLOG_URL = process.env.BLOG_URL ?? "http://localhost:4187";
const nextConfig: NextConfig = {
  async rewrites() {
    return [
      { source: "/blog", destination: `${BLOG_URL}/blog` },
      { source: "/blog/:path+", destination: `${BLOG_URL}/blog/:path+` },
      { source: "/blog-static/:path+", destination: `${BLOG_URL}/blog-static/:path+` },
    ];
  },
};
export default nextConfig;

Blog zone next.config.ts: assetPrefix and allowed origins

// blog zone: next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  // Assets are served under /blog-static/_next/... so they never collide with the home zone
  assetPrefix: "/blog-static",
  experimental: {
    serverActions: {
      // the user-facing domain, needed when a proxy in front does not preserve the original host
      allowedOrigins: ["www.example.com"],
    },
  },
};

export default nextConfig;

Linking across zones: plain a tags, not next/link

// home zone: app/page.tsx
import Link from "next/link";
export default function Home() {
  return (
    <main>
      <h1>Home zone</h1>
      <Link href="/products" id="same-zone">Products (same zone)</Link>
      <a href="/blog" id="other-zone">Blog (other zone, plain a tag)</a>
      {/* Avoid: <Link href="/blog"> wastes an RSC request, then does a full load anyway */}
    </main>
  );
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.