Monolith oder Microservices - wann was sinnvoll ist
85 % der Unternehmen setzen heute auf Microservices1 – und viele davon bereuen es. Nicht weil die Architektur schlecht ist, sondern weil sie zum falschen Zeitpunkt eingeführt wurde. Dieser Artikel liefert eine ehrliche Entscheidungsgrundlage: Daten statt Hype.
Das Problem mit dem Architektur-FOMO
„Der CTO hat einen Blogartikel gelesen und wir sollen jetzt alles in Microservices umbauen." Dieser Satz ist eine Karikatur – aber nur knapp. In der Praxis werden Architekturentscheidungen erschreckend oft durch Konferenzvorträge, LinkedIn-Posts und die Angst, technologisch zurückzufallen, getrieben. Das Ergebnis: Teams, die sich mit 342 YAML-Dateien, explodierenden Cloud-Kosten und verteilten Systemen herumschlagen, deren Komplexität keiner mehr überblickt2.
Die Frage „Monolith oder Microservices?" hat keine generelle Antwort. Sie hat nur eine kontextabhängige.
Was die Daten sagen
Bevor Meinungen kommen, erst die Fakten. Eine Reihe empirischer Studien aus den Jahren 2024 und 2025 liefert konkrete Zahlen:
Das ist aufschlussreich. Microservices liefern messbare Vorteile – aber nur unter den Bedingungen, für die sie konzipiert wurden: hohe Last, unabhängige Deployments, getrennte Teams. Wer diese Bedingungen nicht erfüllt, zahlt den Preis (buchstäblich) ohne den Gegenwert zu erhalten.
Microservices performen unter Hochlast besser – solange die Infrastruktur mitspielt. Überschreitet die CPU-Auslastung 90 %, dreht sich der Vorteil um: Die Koordination zwischen Services kostet mehr, als die Verteilung einspart. Wer Microservices einsetzt, braucht deshalb von Anfang an ein funktionierendes Autoscaling, Lastverteilung und Kapazitätsplanung – nicht als Nachbesserung, sondern als Teil des Architekturentwurfs. 3
Ein systematisches Literature Review von 20254 fasst den Stand der Forschung so zusammen: Für neue oder kleine Projekte ist der Monolith schneller und günstiger. Microservices skalieren besser und ermöglichen echte Team-Autonomie – aber um den Preis erheblicher Betriebskomplexität.
Der entscheidende Schwellenwert: Teamgröße
Der wichtigste Einflussfaktor auf die richtige Architekturwahl ist nicht die Codebasis, nicht der Tech-Stack und nicht das Skalierungsversprechen. Es ist die Teamgröße.
| Teamgröße | Empfehlung | Begründung |
|---|---|---|
| 1–10 Entwickler | ●Monolith | Microservices-Overhead überwiegt den Nutzen. Koordinationskosten gering, ein Deploy-Ziel schneller. |
| 10–50 Entwickler | ●Modularer Monolith | Strukturierung notwendig, aber verteilte Systeme noch nicht gerechtfertigt. Sweet Spot. |
| 50+ Entwickler | ●Microservices sinnvoll | Koordinationskosten rechtfertigen den Investitionsaufwand. Autonome Teams arbeiten parallel. |
Diese Schwellenwerte sind kein Bauchgefühl. Sie stammen aus DORA-Metriken, Performance-Studien und Industry-Surveys von 2024/252. Experten haben 2025 erstmals expliziten Konsens formuliert: Unter 10 Entwicklern performen Monolithe besser, und Docker fügt dort nur Komplexität ohne erkennbaren Nutzen hinzu5.
Der dritte Weg: Modularer Monolith
Die Debatte wird zu häufig als Binärentscheidung gerahmt. Es gibt einen dritten Weg, der in der Praxis oft die beste Lösung ist: den Modularen Monolith – oder in modernem Java-Kontext: Spring Modulith.
Die Idee ist simpel: Eine Applikation, intern sauber nach Domänen geschnitten, mit erzwungenen Modulgrenzen – aber ohne das Overhead verteilter Systeme. Ein Deployment-Artefakt, eine Datenbank, null Netzwerklatenzen zwischen Modulen.
Mit @ApplicationModule und @NamedInterface erzwingt Spring Modulith Architekturgrenzen zur Compile-Zeit.
ArchUnit validiert automatisch, dass kein Modul auf die Interna eines anderen zugreift.
Das Ergebnis ist ein System, das sich wie Microservices strukturiert verhält – ohne deren Betriebsaufwand.6
Der entscheidende strategische Vorteil: Ein sauber modularisierter Monolith lässt sich bei Bedarf schrittweise in Microservices extrahieren. Wer von Anfang an Systemgrenzen definiert und Module mit klaren öffentlichen APIs versieht, betreibt keinen Rückbau bei der Migration – er schließt nur einen Prozess ab, der ohnehin schon begonnen hat. Wer hingegen mit einem unstrukturierten Monolith startet, trägt den technischen Schulden-Rucksack durch die Tür.
Gegenüberstellung: Monolith · Modularer Monolith · Microservices
| Dimension | Monolith | Modularer Monolith | Microservices |
|---|---|---|---|
| Deployment | ●1 Artefakt | ●1 Artefakt | ●N unabhängige Services |
| Time-to-Market (initial) | ●Sehr schnell | ●Schnell | ●Langsam |
| Time-to-Market (langfristig) | ●Langsam | ●Schnell | ●Schnell |
| Skalierbarkeit | Gesamtes System | Gesamtes System | ●Granular pro Service |
| Fehlertoleranz | ●Keine Isolation | ●Begrenzt | ●Hoch |
| Transaktionskonsistenz | ●ACID nativ | ●ACID nativ | ●Eventual Consistency, Saga-Pattern nötig |
| Betriebsaufwand | ●Gering | ●Gering | ●Hoch (Service Mesh, Tracing, CI/CD je Service) |
| Testbarkeit | ●E2E einfach | ●Modultests + E2E | ●Komplex (Contract Tests, Integrationstests verteilt) |
| Migration zu Microservices | ●Schwierig | ●Vorbereitet | – |
Wann Microservices tatsächlich sinnvoll sind
Es wäre falsch, Microservices pauschal zu verteufeln. Für die bestimmte Situationen sind sie die richtige Antwort. Die folgende Liste liefert organisatorische und fachliche Signale – kein einzelnes Kriterium ist hinreichend, mehrere zusammen sind ein klares Zeichen:
- Teams > 10 Entwickler, die unabhängig deployen müssen
- Klar unterschiedliche Skalierungsanforderungen pro Domäne
- Unterschiedliche Release-Zyklen verschiedener Systemteile
- Compliance-Anforderungen erfordern Service-Isolation
- Geografisch verteilte Teams mit Ownership je Domain
- Teile des Systems sollen in anderen Technologien gebaut werden
- Kleines Team, gemeinsamer Deployment-Rhythmus
- Domänen sind noch nicht stabil definiert
- Starke transaktionale Konsistenz über Domänengrenzen nötig
- Kein reifes CI/CD, kein Observability-Stack vorhanden
- Prototyp oder MVP in früher Phase
- Kein dediziertes DevOps / Platform-Engineering-Team
Das gefährlichste Ergebnis einer gescheiterten Microservices-Migration ist kein Monolith mehr und noch kein echtes verteiltes System. Services kommunizieren synchron in langen Ketten, jede Änderung erfordert Koordination über mehrere Services, Deployments hängen trotzdem voneinander ab. Die gesamte Komplexität verteilter Systeme, keiner der Vorteile. Erkennbar an: enger synchroner Kopplung statt Event-Driven, fehlendem Datenbankschnitt per Service, Deployments die nicht wirklich unabhängig sind.
Die Parallelen zu realen Projekten
Ein bekanntes Beispiel aus der Industrie: Amazon Prime Video migrierte einen ihrer Videoüberwachungs-Services Anfang 2024 zurück von einer verteilten Microservice-Architektur in einen Monolith – und reduzierte die Infrastrukturkosten dabei um 90 %. Der Grund: Die ursprüngliche Zerlegung führte zu einem Distributed Monolith mit hohem Datenübertragungsvolumen zwischen Services, ohne echten Skalierungsvorteil zu liefern.
Auf der anderen Seite betreibt Netflix über 1.000 Microservices und deployt täglich tausende Male7. Das funktioniert, weil Netflix mehrere tausend Entwickler hat, ein ausgereiftes Platform-Engineering-Team und Jahrzehnte Erfahrung im Betrieb verteilter Systeme. Das ist kein Modell für ein mittelständisches Unternehmen mit einem dreiköpfigen Entwicklungsteam.
Empfehlung: Wie ich an Architekturentscheidungen herangehe
In der Praxis empfehle ich für die meisten Projekte einen klaren Startpunkt: Modularer Monolith mit Spring Modulith, Domain-Driven Design und sauberem Bounded-Context-Schnitt. Das liefert von Tag eins strukturierten, wartbaren Code, ermöglicht schnelle initialen Entwicklung und lässt alle Optionen offen.
Die Entscheidung, einzelne Module in eigenständige Services herauszulösen, trifft man dann nicht auf Basis von Architektur-Hype, sondern auf Basis konkreter Signale: Deployment-Konflikte zwischen Teams, messbarer Skalierungsbedarf an einem spezifischen Teil, oder Compliance-Anforderungen, die Service-Isolation erzwingen.
Fang nicht mit Microservices an. Fang mit einem modularen System an, das sich wie Microservices verhält – aber einfacher zu betreiben ist. Wächst das System und das Team, sind die Grenzen bereits gezogen. Die Migration wird zum Abschluss eines begonnenen Prozesses, nicht zu einem Neustart.
Fazit
Die richtige Architektur ist nicht die modernste, nicht die, die Netflix benutzt, und nicht die, die auf der letzten JAX besonders viele Zuhörer hatte. Die richtige Architektur ist die, die zu Teamgröße, Projektphase, Betriebskapazität und fachlicher Komplexität passt – und dabei Raum lässt zu wachsen, ohne sich frühzeitig festzulegen.
Für die meisten mittelständischen Java-Projekte ist das 2025 ein Modularer Monolith auf Basis von Spring Boot. Gut geschnitten, mit klaren Domain-Grenzen, versionierten Schnittstellen und einem CI/CD-Setup, das späteres Herauslösen von Services nicht zur Mammutaufgabe macht.
Unsicher, welche Architektur zu Ihrem Projekt passt?
In einem strukturierten Architektur-Review analysiere ich Ihren geplanten oder bestehenden Systemschnitt und liefere konkrete Handlungsempfehlungen – in einem halben Tag für 690 € netto, als schriftliches Ergebnis.
Zum Architektur-Review- Pawel Piwosz, „Monolith vs Microservices 2025: real cloud migration costs and hidden challenges", Medium, 2025. Daten basieren auf 2024-Surveys.
- Ebd. DORA-Metriken, Performance-Studien und Industry-Surveys 2024/25.
- Marieska et al., „Performance Comparison of Monolithic and Microservices Architectures in Handling High-Volume Transactions", Jurnal RESTI, Vol. 9 No. 3, 2025.
- Systematic Literature Review, Preprints.org, November 2025 (nicht peer-reviewed zum Zeitpunkt der Recherche).
- Foojay.io, „Monolith vs Microservices 2025", August 2025.
- Vinod Jagwani, „Building Scalable Modular Monoliths with Spring Boot Modulith", Medium, 2025.
- Java Code Geeks, „Microservices vs. Modular Monoliths in 2025: When Each Approach Wins", Dezember 2025.