dewasemadi.com

Breaking Down the Monolith: A Guide to Scalable Next.js Multi-Zone Architecture

•5 min read•
#next.js#architecture#scalability#monorepo
Breaking Down the Monolith: A Guide to Scalable Next.js Multi-Zone Architecture

Cover photo by William Warby on Unsplash

#1. The Growing Pains of Success

#1.1 The One-Building Problem

Imagine you are building a university. In the beginning, it's just one building. You have the Library on the first floor, the Gym on the second, and the Dorms on the third. Everything is reachable. If you need to fix a pipe in the Gym, you just walk upstairs.

But as the university grows, that building becomes 100 floors tall. Now, to fix that same pipe, you have to shut down the water for the Dorms and the Library too. This is exactly what happens to successful software applications. We call this the "Monolith".

In a monolith, every feature such as the Library catalog, the Gym class schedule, and the Dorm room assignments lives in one giant code "building." When a developer wants to update the Library hours, they have to rebuild the entire application to ensure they did not accidentally break the Dorm keycard system.

#1.2 Why It Gets Slow

Technically speaking, our build tools work by checking connections. In a massive application, this web of connections is huge.

  • Small App: 3 minutes to verify everything.
  • Huge Enterprise App: 45 minutes to 1 hour.

This means if a developer fixes a typo, they wait an hour to see it live. This destroys productivity. We hit a ceiling where adding new features actually slows us down.

#2. The Solution: "The Campus" Strategy

Instead of building one giant skyscraper, what if we built a University Campus?

  • The Library is its own building.
  • The Genatorium is its own building.
  • The Dorms are their own buildings.

They are all separate, but they are connected by walkways. If the Library needs a renovation, you don't have to close the Gym. The students (users) just see one cohesive "University," but the maintenance teams (developers) treat them as separate projects.

In the world of Next.js, we call this Multi-Zone Architecture.

#2.1 Visualizing the Difference

Here is how a standard Monolith looks. Everything is trapped in one box:

And here is the Multi-Zone (Campus) approach. The "Shell" acts like the campus security guard, directing traffic to the right building:

#3. How It Works (The "Walkways")

To the user, this split is invisible. They just click a link.

  1. User visits example.com. They land on the Shell (The main entrance).
  2. User clicks "Finance".
  3. The Shell says, "Oh, you want the Finance building? Use this walkway."
  4. The browser seamlessly loads the Finance App.

#3.1 The "Traffic Controller" Code

We use a feature called Rewrites to act as the traffic controller. This code lives in the Shell's configuration file (next.config.js).

// This is the Shell's instruction manual
module.exports = {
  async rewrites() {
    return [
      {
        source: "/finance", // If user asks for /finance...
        destination: "http://finance-app-url/finance", // ...send them to the Finance App
      },
      {
        source: "/hr", // If user asks for /hr...
        destination: "http://hr-app-url/hr", // ...send them to the HR App
      },
    ]
  },
}

#3.2 Keeping the Look Consistent

The biggest risk with separate apps is that they might look different. We don't want the Header to look blue in Finance but green in HR.

To solve this, we create a shared Design System (a shared box of Lego bricks). Both the Finance App and the HR App import their buttons, headers, and layouts from this shared box.

// Shared 'Lego' Component
import { Header, Footer } from "@company/ui-kit"
import type { PropsWithChildren } from "react"
 
export const GlobalLayout = ({ children }: PropsWithChildren) => (
  <div>
    <Header /> {/* Exact same header everywhere */}
    <main>{children}</main>
    <Footer />
  </div>
)

#4. Trade-offs: The Cost of Separation

No architecture is perfect. The "Campus" approach has one main downside compared to the "Skyscraper."

The "Walkway" Pause: In a Monolith (Skyscraper), moving between rooms is instant. In a Campus, walking between buildings takes a second. Technically, this means moving from the Finance App to the HR App triggers a "Hard Reload." The browser has to dump the memory of the first app and load the second one.

Is this a problem? For an Instagram-like app? Yes. For a serious business tool? No. Users typically stay in one "mode" (like Finance) for hours. The split second it takes to switch modes is worth the massive increase in stability and speed for the engineering team.

#5. Summary

Moving to a Multi-Zone architecture allows large teams to move fast again.

  • Deployments are safer: Breaking Finance doesn't break HR.
  • Upgrades are easier: One team can upgrade their tools without forcing everyone else to.
  • Testing is faster: You only test the building you changed.

It's the professional way to grow up from a startup to an enterprise.

#6. References & Further Reading

For those who want to dive deeper into the technical details, here are the official resources used to design this architecture:

  1. Next.js Documentation: Multi-Zones - The official guide on setting up rewrites.
  2. Turborepo: Remote Caching - How to speed up builds in a monorepo.
  3. Vercel Guides: Micro-Frontends with Next.js - A deep dive into the different approaches to frontend splitting.
Share this article