Modulare Monolithen ersetzen Microservices in mittelgroßen Engineering-Teams

Den größten Teil des letzten Jahrzehnts galt die Aufteilung einer Anwendung in Microservices als die verantwortungsvolle Entscheidung — das, was man tat, sobald Skalierung wirklich wichtig wurde. Im Jahr 2026 kehrt eine wachsende Zahl von Engineering-Teams diese Entscheidung still um, nicht indem sie Service-Grenzen aufgeben, sondern indem sie sie wieder in eine einzige bereitstellbare Einheit mit strikter interner Modultrennung zusammenführen: den modularen Monolithen.

Das klarste öffentliche Beispiel bleibt Amazons Prime-Video-Team, das 2023 seinen Videoqualitäts-Analysedienst von einer verteilten, auf Lambda und Microservices basierenden Pipeline in einen einzigen monolithischen Prozess verlagerte. Das Team berichtete von einer Infrastrukturkostensenkung von etwa 90% für diesen spezifischen Dienst, zusammen mit deutlich einfacherem Debugging.

Warum das Pendel zurückschwang

Microservices lösen ein spezifisches Problem: unabhängige Bereitstellbarkeit und unabhängige Skalierung für Teams, die groß genug sind, dass eine gemeinsame Codebasis zu einem Koordinationsengpass wird. Für eine 200-köpfige Engineering-Organisation, aufgeteilt in Dutzende autonome Teams, ergibt dieser Kompromiss Sinn. Aber für ein 15-köpfiges Team, das 40 Microservices betreibt, verschlingt der operative Overhead den vermeintlichen Nutzen.

Basecamp und Shopify haben beide öffentlich beschrieben, bei einem «majestätischen Monolithen»-Modell zu bleiben oder dorthin zurückzukehren, anstatt sich in Dutzende Services aufzuteilen, mit derselben Begründung: Die meisten ihrer Anfragepfade benötigen keine unabhängige Skalierung.

Wie ein modularer Monolith tatsächlich aussieht

Ein modularer Monolith bedeutet nicht «aufgeben und Spaghetti-Code in einer einzigen Datei schreiben». Es ist eine einzige bereitstellbare Anwendung, die intern in Pakete oder Module mit expliziten, erzwungenen Grenzen organisiert ist — typischerweise ein Modul pro Geschäftsdomäne (Abrechnung, Bestand, Benachrichtigungen). Jedes Modul besitzt seine eigene Datenzugriffsschicht und stellt anderen Modulen eine schmale interne Schnittstelle bereit.

Das bringt die meisten Vorteile, die man ursprünglich von Microservices wollte, ohne die Steuer verteilter Systeme: keine Netzwerklatenz zwischen Modulen, keine Behandlung von Teilausfällen für Aufrufe, die früher Funktionsaufrufe waren.

Wann Microservices ihre Kosten noch rechtfertigen

Das ehrliche Argument für Microservices existiert weiterhin. Wenn eine einzelne Komponente unabhängig 50-mal stärker skalieren muss als der Rest des Systems, ist deren Auslagerung die richtige Entscheidung. Die praktische Regel, die sich 2026 unter Teams herausgebildet hat: Standardmäßig einen modularen Monolithen verwenden und einen Service nur extrahieren, wenn man die spezifische Skalierungs-, Sprach- oder Team-Autonomie-Anforderung benennen kann, die dies rechtfertigt.

Erkenntnisse für Teams, die ihre Architektur überdenken

Wenn Ihr Team etwa 50 Ingenieure oder weniger hat und mehr als eine Handvoll Services betreibt, prüfen Sie, welche Services tatsächlich unabhängige Skalierungsanforderungen haben im Vergleich zu denen, die aus organisatorischen Gründen aufgeteilt wurden, die nicht mehr gelten. Behalten Sie die Modulgrenzen; entfernen Sie die Netzwerk-Hops.