Vom monolithischen Frontend zur Next.js Multi-Zone-Architektur (Vom Monolithischen Frontend Zu Nextjs Multi Zone)

Referenzhinweis

Diese Serie teilt Entscheidungen und Designansätze aus Erfahrungen in echten Production-Systemen. Sie enthält keinen nicht öffentlichen Source Code, keine Kundendaten, Infrastrukturkonfigurationen oder internen Betriebsinformationen. Beispiele sind unter Wahrung von Vertraulichkeitsverpflichtungen generalisiert oder anonymisiert.

Das Ausgangsproblem

Ein monolithisches Frontend ist kein schlechter Start. Bei einem Team, einem Liefer-Rhythmus und einer begrenzten Produktfläche besitzt es die geringsten Betriebskosten. Spannung entsteht, wenn Katalog, Suche, Warenkorb, Checkout, Account und Merchant-Erlebnis mit unterschiedlicher Geschwindigkeit ändern.

Ein Frontend
  → eine Build-Queue
  → ein Release-Fenster
  → unabhängige Änderungen warten aufeinander

Die Frage lautet nicht, wie Multi-Zone gebaut wird. Sie lautet: Welche Evidenz macht eine Frontend-Grenze wertvoller als die zusätzliche Komplexität?

Begriffe bei der ersten Verwendung

📦 Zone
Eine unabhängig deploybare Client-Anwendung für einen definierten URL-Bereich und eine Nutzerintention.

📦 Gateway
Der Einstieg hinter einer öffentlichen Domain, der Requests an die richtige Zone leitet.

📦 Independent Deployment
Eine Domain-Änderung ohne Bindung an ein fremdes Release-Fenster ausliefern.

📦 Blast Radius
Die Nutzer und Systemfläche, die ein Fehler oder eine Änderung betreffen kann.

Eine Zone trennt nicht nur Ordner. Sie trennt auch Ownership, Deployment, Observability und Rollback-Entscheidungen.

Warum ein Monolith irgendwann langsamer wird

In einem Marketplace ändert die Suche ihre Filter- und Indexlogik oft. Warenkorb und Checkout verlangen höhere Sicherheit und kontrolliertere Releases. Merchant Tools sollen sich unabhängig von der Buyer Journey entwickeln. Ein gemeinsames Deployment erzeugt dadurch gemeinsame Koordination statt wertvolles Code Sharing.

Die Alternativen

Alternative	Stärke	Akzeptierte Kosten
Eine Anwendung	Geringste lokale Komplexität	Gemeinsames Release-Fenster und wachsender Blast Radius
Module Federation	Runtime-Modul-Komposition	Versions-, Runtime- und Debugging-Kosten
Next.js Multi-Zone	Unabhängiges Deployment nach URL-Domain	Routing-, Asset- und Cross-Zone-Contract-Disziplin
Separate öffentliche Domains	Starke Isolation	Fragmentierte Session, UX und SEO

Multi-Zone ist sinnvoll, wenn unabhängige Veränderung und eine einheitliche Nutzeroberfläche gleichzeitig nötig sind. Der Browser sieht ein Produkt; Teams sehen verantwortete Client-Domains.

Die Entscheidung: URL-Grenzen an Business-Grenzen ausrichten

Jede Zone besitzt einen URL-Bereich, dessen Nutzerintention und Release-Verantwortung. Das Gateway erhält eine Produktoberfläche und routet Requests an die passende Ownership-Grenze. Route Ownership muss an einer Stelle deklariert sein. Andernfalls beanspruchen Zonen denselben Path, Locale-Verhalten driftet und Redirects wachsen unsichtbar.

Browser → Gateway
  → Katalog-Zone
  → Search-Zone
  → Cart- und Checkout-Zone
  → Account-Zone

Der Trade-off

Independent Deployment ist nicht kostenlos. Jede Zone fügt Build-, Deploy-, Health-, Rollback-, Security- und Ownership-Kosten hinzu. Cross-Zone State braucht eine explizite Autorität und einen Contract statt eines globalen Client Stores, der unbemerkt zum nächsten Monolithen wird.

Production Learnings

• Assets brauchen isolierte Prefixes und Cache Policy.
• Gateway Routing muss dynamische Paths und Locales bewahren.
• Session Refresh und Logout brauchen Cross-Zone-Tests.
• Independent Deployment verlangt auch unabhängigen Rollback.
• Correlation IDs und Route-Level-Metriken machen eine User Journey über Zonen beobachtbar.

Was ich heute ändern würde

Ich würde Zonen nicht früher erzeugen. Zuerst würde ich Route Ownership, Team-Unabhängigkeit und messbare Release-Reibung beweisen. Shared UI, Auth, Types und Utilities blieben eng und versionierbar. Ein Shared Package als unbegrenzter gemeinsamer Raum erzeugt erneut den Monolithen.

Das erste Ziel wäre niedrigste Koordinationskosten, nicht die höchste Anzahl von Zonen.

Häufige Verwechslungen

❌ Multi-Zone bedeutet eine Anwendung pro Seite
✓ Eine Zone ist die Grenze unabhängig veränderbarer Nutzerintention und Ownership.

❌ Multi-Zone garantiert Micro-Frontend-Erfolg
✓ Route-, Asset-, Session- und Rollback-Contracts müssen gestaltet werden.

❌ Shared Package bedeutet alles zentralisieren
✓ Es ist für stabile, wirklich gemeinsame Contracts gedacht.

Entscheidungs-Checkliste

1. Hat der Bereich wirklich eine andere Nutzerintention, einen anderen Owner und Release-Rhythmus?
2. Verringert die Grenze den Blast Radius?
3. Sind Route-, Locale- und Asset-Ownership explizit?
4. Ist die Autorität für Session und Cross-Zone State klar?
5. Hat jede Zone Health-, Rollback- und Observability-Signale?
6. Sind die Kosten gegenüber Module Federation oder einem modularen Monolithen aufgeschrieben?

Eine Grenze ist nur wertvoll, wenn sie neben Deployment-Zeit auch Test-, Incident- und Entscheidungskosten senkt.

Was im Gedächtnis bleiben sollte

Multi-Zone existiert nicht, um ein Frontend zu fragmentieren. Es begrenzt die Wirkung von Veränderung auf die richtige Grenze.

Ein Monolith kann lange die richtige Wahl bleiben. Trennung wird erst sinnvoll, wenn unabhängige Veränderung, Fehlerisolation und kontrollierte Lieferung nachweislich nötig sind.

Nächstes Kapitel: Warum nicht Module Federation?