Die Rückkehr des Monolithen: Architektur im KI-Zeitalter

Zwölf Leute, 23 Services

Ein Muster, das wir in Architektur-Audits immer wieder sehen: ein Startup mit zwölf Mitarbeitenden, davon neun in der Entwicklung. Die Plattform besteht aus 23 Microservices, verteilt über 23 Repositories. Dazwischen vier Message-Queues, ein Service-Mesh, eine Handvoll selbstgebauter Shared Libraries in drei Versionsständen. Drei der neun Entwickler bilden ein „Platform-Team", das nichts anderes tut, als diese Maschinerie am Laufen zu halten.

Was kostet das pro Feature? Nimm etwas Banales: Ein Kunde soll beim Checkout einen Gutscheincode eingeben können. In diesem System berührt die Änderung den Checkout-Service, den Pricing-Service, den Order-Service und das Frontend-BFF. Vier Repos, vier Pull Requests, vier Deploys in der richtigen Reihenfolge, ein Contract-Update zwischen Pricing und Order – und wenn beim ersten Test etwas nicht stimmt, beginnt die Suche im Distributed Tracing: Welcher der vier Services hat den Gutschein verschluckt?

Ein Feature, das in einer einzigen Codebasis ein Nachmittag wäre, dauert hier eine Woche. Nicht, weil die Logik schwierig ist, sondern weil die Architektur jede Änderung in Stücke schneidet und über Netzwerkgrenzen verteilt. Das Team hat sich die Koordinationskosten eines Konzerns eingekauft – ohne den Konzern.

Warum Microservices die 2010er gewonnen haben

Um fair zu bleiben: Microservices haben sich nicht aus Dummheit durchgesetzt. Sie lösten ein echtes Problem – nur war es selten ein technisches.

1967 formulierte Melvin Conway die Beobachtung, die später als Conways Gesetz bekannt wurde: Systeme spiegeln die Kommunikationsstruktur der Organisation, die sie baut. Wer 50 Teams hat, die unabhängig voneinander releasen wollen, braucht eine Architektur, in der 50 Teile unabhängig deploybar sind. Der Monolith mit seinem einen Release-Zug, auf den alle warten mussten, war für Amazon, Netflix oder Spotify ein organisatorischer Flaschenhals. Microservices haben ihn aufgelöst.

Dazu kamen echte technische Vorteile: Hot Paths unabhängig skalieren, verschiedene Sprachen für verschiedene Probleme, Ausfälle auf einen Service begrenzen. Alles legitim – bei der Größe, für die es erfunden wurde.

Dann kam das Cargo-Culting. Konferenzvorträge aus Unternehmen mit tausend Entwicklern wurden zu Blaupausen für Teams mit zehn. Die Frage „Haben wir das Problem, das Microservices lösen?" wurde durch „So macht man das heute" ersetzt. Netflix braucht Hunderte unabhängig deploybarer Dienste. Ein Zwölf-Personen-Startup braucht sie nicht. Es hat sie trotzdem gebaut, weil die Vorlage eben so aussah.

Dass das Pendel zurückschwingt, ist nicht neu. Segment hat schon 2018 öffentlich beschrieben, wie das Unternehmen von Microservices zurück zu einem Monolithen gewechselt ist, weil der operative Overhead außer Kontrolle geraten war. Amazon Prime Video berichtete 2023 im eigenen Tech-Blog, dass sein Audio-/Video-Qualitätsmonitoring von einer verteilten Serverless-Architektur aus Step Functions und Lambdas in einen einzelnen Prozess überführt wurde – und die Infrastrukturkosten um rund 90 % sanken. DHH und 37signals predigen seit Jahren den „Majestic Monolith". Shopify betreibt eine der größten Rails-Codebasen der Welt bewusst als modularen Monolithen.

Neu ist, dass KI-Agenten zwei Eingangsgrößen dieser Rechnung gleichzeitig verändern.

Was Agenten ändern, erstens: Kontext

Ein Coding-Agent ist genau so gut wie das, was er gleichzeitig sehen kann. Das ist keine Nebensächlichkeit, es ist die zentrale Eigenschaft dieser Werkzeuge. Ein Agent, der einen Call-Path vom HTTP-Handler über die Geschäftslogik bis zur Datenbanktabelle in einem Repository verfolgen kann, trifft bessere Entscheidungen als einer, der an einer Service-Grenze ins Leere greift.

Microservices sind, aus dieser Perspektive betrachtet, eine Architektur des versteckten Kontexts. Die Logik einer einzigen Benutzeraktion – „Gutschein einlösen" – ist über N Repositories verschmiert. Von dem Repo aus, in dem der Agent startet, sieht er nur einen HTTP-Call ins Nichts. Was auf der anderen Seite passiert, welche Felder der Contract wirklich erwartet, welcher Service die Nebenwirkung auslöst, die den Fehler erzeugt: Nichts davon ist von seiner Position aus sichtbar. Er muss es entdecken, klonen, korrelieren – wenn er überhaupt die Zugangsdaten für die anderen Repos hat.

Konkret zahlt ein Agent in einer Microservice-Landschaft die Integrationssteuer zweimal:

• Einmal beim Entdecken. Welche Services sind beteiligt? Wo liegt der Code? Welche Version des Contracts gilt gerade – die im OpenAPI-Dokument oder die, die tatsächlich deployt ist? Contracts driften in der Praxis immer, und der Agent sieht nur eine Seite.
• Einmal beim Ändern. Vier Repos, vier Branches, vier PRs, die zueinander passen müssen, vier Deploys in Abhängigkeit. Jede Grenze ist ein Punkt, an dem eine Inkonsistenz unbemerkt bleiben kann, weil kein Compiler und kein Typsystem über die Netzwerkgrenze hinweg prüft.

Dazu kommt das Testen. In einem Monolithen kann ein Agent die gesamte Testsuite lokal ausführen und bekommt in Minuten eine Antwort, ob seine Änderung irgendetwas anderes bricht. In einer Microservice-Landschaft gibt es diese Antwort nur in einer Integrationsumgebung, die für den Agenten meist unerreichbar ist – und die, wenn man ehrlich ist, auch für Menschen nur halbwegs verlässlich funktioniert.

Erste Praxisberichte und kleine Benchmarks aus diesem Jahr deuten in dieselbe Richtung: Agenten produzieren auf modularen Monolithen korrektere Multi-File-Änderungen als auf Microservice-Landschaften, schlicht weil der vollständige Call-Graph in einem Repository sichtbar ist. Die Zahlen sind noch zu dünn für Präzision, aber der Mechanismus ist einleuchtend. Wer das ganze Spielfeld sieht, spielt besser.

Was Agenten ändern, zweitens: Teamgröße

Der zweite Hebel ist organisatorisch, und er greift Conways Gesetz direkt an.

In „Das Zwei-Personen-Team, das eine Abteilung ersetzt" haben wir beschrieben, wie Agenten die Produktivität kleiner Teams verschieben: Zwei, drei Leute liefern heute, wofür vor wenigen Jahren eine Abteilung nötig war. Das ist kein Marketingsatz, sondern das, was wir bei Kunden sehen.

Zu Ende gedacht heißt das: Wenn drei Menschen das Produkt bauen, gibt es keine Teamgrenzen, die eine Architektur spiegeln müsste. Es gibt kein Checkout-Team, das unabhängig vom Pricing-Team deployen muss, weil es keine zwei Teams gibt. Der organisatorische Grund für Microservices – unabhängige Release-Kadenz für unabhängige Teams – löst sich für die große Mehrheit der Unternehmen schlicht auf. Was bleibt, sind die Kosten.

Conways Gesetz gilt weiterhin. Nur spiegelt die Architektur jetzt die tatsächliche Organisation: ein kleines Team, ein System.

Der modulare Monolith, konkret

„Monolith" klingt für viele nach dem Big Ball of Mud, aus dem sie vor zehn Jahren geflohen sind. Darum geht es nicht. Es geht um den modularen Monolithen: ein Deployable, harte interne Grenzen.

Was das in der Praxis bedeutet:

• Ein Deployable. Eine Codebasis, ein Build, ein Deploy. Das Gutschein-Feature ist ein PR, ein Review, ein Release.
• Module mit expliziter öffentlicher Schnittstelle. Checkout, Pricing, Orders, Billing sind getrennte Module mit klar deklarierten Public APIs. Was nicht exportiert ist, ist von außen unsichtbar – nicht per Konvention, sondern per Regel.
• Durchgesetzte Grenzen. Import-Linting, das einen Verstoß im CI scheitern lässt. Module-Ownership, die festlegt, wer eine Schnittstelle ändern darf. Shopify hat dafür Packwerk gebaut; in anderen Ökosystemen tun es Tools wie dependency-cruiser, ArchUnit oder die Module-Boundaries von Nx.
• Eine Datenbank, klare Zuständigkeit. Ein Schema pro Modul, oder zumindest eine eindeutige Regel, welchem Modul welche Tabellen gehören. Kein Modul schreibt in die Tabellen eines anderen; Cross-Module-Fragen gehen über die Schnittstelle.
• Asynchron zuerst in-process. Domain-Events über einen internen Event-Bus, nicht über Kafka. Dieselbe Entkopplung, ohne das Netzwerk, ohne die Queue, ohne das Betriebsteam.
• Extrahieren nur mit gemessenem Grund. Erst wenn ein Modul nachweislich anders skalieren, anders isoliert oder von einem anderen Team verantwortet werden muss, wird daraus ein Service. Nicht vorher, nicht vorsorglich.

Und hier kommt die Pointe, die das Ganze erst im KI-Zeitalter aufgehen lässt. Der klassische Grund, warum Monolithen verrotteten, war nie die Architektur. Es waren Menschen unter Termindruck, die eine Grenze „nur dieses eine Mal" übersprungen haben: ein direkter Datenbankzugriff am Modul vorbei, ein Import aus dem Internals-Ordner, weil es Freitagnachmittag war. Hundert solcher Entscheidungen später war der Monolith ein Ball of Mud.

Genau diese Art von Disziplin ist es, die ein Agent unermüdlich liefert. Er wird nie müde, eine Lint-Regel zu beachten. Er überspringt keine Grenze, weil der Release morgen ist. Als Reviewer markiert er den hundertsten Verstoß so konsequent wie den ersten. Die Schwäche, an der Monolithen historisch gescheitert sind, ist genau die, die ein unermüdlicher Prüfer ausgleicht. Das macht den modularen Monolithen nicht nur wieder möglich, sondern erstmals robust gegen seinen eigenen Verfall.

Wo Microservices weiterhin gewinnen

Jetzt die ehrliche Gegenseite, denn „Monolith für alle" wäre dasselbe Cargo-Culting in umgekehrter Richtung.

Es gibt Fälle, in denen Microservices die richtige Antwort bleiben:

• Wirklich unabhängige Skalierung. Video-Transcoding und CRUD-Formulare haben nichts gemeinsam – nicht im Ressourcenprofil, nicht im Kostenverlauf, nicht in der Hardware. Solche Pfade gehören getrennt.
• Regulatorische oder Datenisolation. Wenn Zahlungsdaten in einer PCI-Zone leben müssen oder Gesundheitsdaten in einer eigenen Infrastruktur, ist die Service-Grenze eine Compliance-Grenze, kein Architekturgeschmack.
• Echter Polyglot-Bedarf. Ein ML-Inferenzpfad in Python neben einem Kernsystem in Go oder Java ist ein legitimer Grund für zwei Deployables.
• Organisationen oberhalb von etwa 100 Entwicklern mit wirklich unabhängigen Release-Kadenzen. Dort gilt Conways Gesetz in seiner ursprünglichen Richtung, und die Architektur sollte das abbilden.
• Blast-Radius-Isolation für kritische Pfade. Der Login darf nicht fallen, weil das Reporting-Modul ein Speicherleck hat.
• Grenzen zu Dritten. Ein Partner-API-Gateway, das ein externes Unternehmen anspricht, ist naturgemäß ein eigenes System.

Eine verbreitete Faustregel für 2026: modularer Monolith für ungefähr 10 bis 100 Entwickler; Microservices darüber, wenn echte Skalierungs-, Polyglot- oder Isolationsgründe vorliegen. Faustregeln sind keine Gesetze, aber diese bildet die Realität der meisten Unternehmen besser ab als die Blaupausen der 2010er.

Und noch eine Warnung, die man nicht unterschlagen darf: Ein Monolith ohne Grenzen plus ein Agent, der schnell Code generiert, ist der schnellste Weg zum Big Ball of Mud, der je erfunden wurde. Alles, was oben über Disziplin gesagt wurde, gilt nur, wenn die Grenzen existieren und maschinell geprüft werden. Ein Agent, der ohne Lint-Regeln und ohne Modulstruktur in eine große Codebasis schreibt, produziert in einer Woche die Kopplungen, für die ein menschliches Team zwei Jahre gebraucht hätte. Die Architektur ist die Voraussetzung, nicht das Nebenprodukt.

Praktische Leitlinien

Wer heute ein System beginnt oder ein bestehendes neu ausrichtet, fährt mit fünf Regeln gut:

1. Starte als modularer Monolith. Nicht als Monolith mit der Absicht, später Module einzuziehen – die Absicht überlebt den ersten Sprint nicht.
2. Grenzen am ersten Tag. Modulstruktur, Import-Regeln, Ownership-Datei, CI-Check. Alles, was später kommen soll, kommt nicht.
3. Messen, bevor du extrahierst. Ein Service entsteht aus einem Profiler-Ergebnis, einer Compliance-Anforderung oder einer Teamgrenze – nie aus einem Bauchgefühl.
4. Halte den Kontext des Agenten klein, auch im Monolithen. Ein README oder eine AGENTS.md pro Modul, die Zweck, Schnittstelle und Regeln beschreibt. Der Agent sieht dann das Ganze, wenn er muss, und das Modul, wenn es reicht. Das knüpft an das an, was wir in „Die Spezifikation ist der neue Quellcode" beschrieben haben: Die Beschreibung des Systems wird zum primären Artefakt, mit dem der Agent arbeitet.
5. Rückweg aus Microservices: Strangler Fig rückwärts. Erst die Repositories in ein Monorepo zusammenführen – das allein gibt dem Agenten die Sichtbarkeit zurück, ohne ein einziges Deployment zu ändern. Dann Services, die keinen gemessenen Grund für ihre Existenz haben, einen nach dem anderen als Modul einziehen. Die Netzwerkgrenze wird zur Funktionsgrenze, die Queue zum In-Process-Event. Wie das Vorgehen bei der Modernisierung bestehender Systeme im Detail aussieht, haben wir in „Legacy-Systeme mit KI-Agenten modernisieren" beschrieben.

Fazit

Microservices haben ein organisatorisches Problem gelöst, das die meisten Unternehmen nie hatten – und das die wenigen, die es hatten, durch KI-Agenten gerade verlieren. Wenn drei Leute liefern, wofür früher eine Abteilung nötig war, gibt es keine Teamgrenzen mehr, die eine Architektur spiegeln müsste. Und wenn das wichtigste neue Werkzeug im Stack am besten arbeitet, sobald es das ganze System auf einmal sieht, dann ist eine Architektur, die den Kontext über zwanzig Repositories verstreut, nicht modern. Sie ist im Weg.

Der modulare Monolith ist die pragmatische Antwort: ein Deployable, harte Grenzen, eine Datenbank mit klarer Zuständigkeit, und ein Agent, der die Disziplin durchsetzt, an der Monolithen früher gescheitert sind. Microservices bleiben das richtige Werkzeug für echte Skalierungs-, Isolations- und Organisationsprobleme – nicht für Startups, die eine Netflix-Vorlage kopiert haben.

Bei nh labs beginnen wir neue Systeme deshalb als modulare Monolithen mit Grenzen vom ersten Tag an, und bei bestehenden Microservice-Landschaften führen wir zuerst die Repositories zusammen, bevor wir überhaupt über Deployables sprechen. Nicht, weil der Monolith nostalgisch wäre. Sondern weil die Rechnung, die ihn vor zehn Jahren verdrängt hat, heute anders ausgeht.