Key Architectural Takeaways
- Next.js Multi-Zones allow separate Next.js apps to be merged into a single user-facing domain with routing handled at the edge/reverse proxy.
- Shared components should be published as lightweight npm packages with peer dependencies to avoid duplicate React runtime loading.
- Cross-application authentication state is best managed via httpOnly secure session cookies and edge middleware verification.
- Do not adopt micro-frontends prematurely; they solve organizational coordination scaling for teams with 30+ engineers.
1. The Monolith Scaling Wall in Growing SaaS Teams
In the early days of a software startup, a single monolithic frontend repository is ideal. Build times are short, refactoring is simple, and shared state is straightforward.
However, as engineering organizations grow beyond 20-30 developers across multiple product pods (e.g. Billing, Core Dashboard, Analytics, Admin Settings), the monolithic repo turns into a massive bottleneck:
- Merge conflicts escalate across release branches.
- CI/CD build and test pipelines stretch from 4 minutes to 25+ minutes.
- A bug in a minor settings page can break the entire critical checkout pipeline.
- Product teams are blocked waiting for global release trains.
This is where **Micro-Frontends** provide autonomy, allowing separate squads to develop, test, and deploy their respective product verticals independently.
2. Next.js Multi-Zones: Clean Modular Routing
Rather than complex iframe stitching or heavy runtime script loading, we champion **Next.js Multi-Zones**. In this architecture, each product domain is an independent Next.js application, stitched seamlessly at the reverse-proxy / edge routing layer.
For example:
- `app.domain.com/` → Root Shell & Navigation App
- `app.domain.com/dashboard/*` → Core Dashboard App
- `app.domain.com/billing/*` → Billing & Invoicing App
- `app.domain.com/analytics/*` → High-Throughput Analytics App
Below is the `next.config.js` rewrites configuration that connects the main shell to independent downstream micro-apps:
next.config.js (Shell App)javascript
/** @type {import('next').NextConfig} */
const nextConfig = {
async rewrites() {
return [
{
source: '/billing',
destination: `${process.env.BILLING_APP_URL}/billing`,
},
{
source: '/billing/:path*',
destination: `${process.env.BILLING_APP_URL}/billing/:path*`,
},
{
source: '/analytics',
destination: `${process.env.ANALYTICS_APP_URL}/analytics`,
},
{
source: '/analytics/:path*',
destination: `${process.env.ANALYTICS_APP_URL}/analytics/:path*`,
},
];
},
};
module.exports = nextConfig;4. Zero-Downtime CI/CD Deployments
With multi-zones, the Billing team can deploy 10 times a day without running the tests of the Analytics or Dashboard apps. CI/CD pipeline runtimes drop from 30 minutes to under 3 minutes per micro-application.
Deployments are routed through Vercel or AWS CloudFront origins, ensuring instantaneous blue-green rollouts and automated rollbacks if canary health checks fail.
5. When to Adopt Micro-Frontends
Micro-frontends are an **organizational architecture** first and a technical architecture second.
- **Adopt them if**: You have multiple independent engineering pods, frequent release contention, and distinct product domains with clear routing boundaries.
- **Avoid them if**: You are a small team (<10 engineers) building an early-stage product where shared domain logic is still fluid.
