Monolith vs Microservices — Architektur-Entscheidung für den Mittelstand 2026

Zwischen 2015 und 2022 galt die Antwort auf praktisch jede Architektur-Frage als selbstverständlich: Microservices. Heute, im Jahr 2026, schwingt das Pendel deutlich zurück. Amazon Prime Video hat eine prominente Video-Monitoring-Pipeline von Serverless-Microservices zurück auf einen Monolith migriert und 90 Prozent Infrastruktur-Kosten gespart. Shopify, einer der lautesten Verfechter, beschreibt sein Kernsystem öffentlich als Modular Monolith. Selbst Netflix relativiert in aktuellen Vorträgen den eigenen Microservice-Kult. Für deutsche mittelständische Unternehmen, die typischerweise mit 10 bis 50 Entwicklern arbeiten, ist diese Wende doppelt relevant: erstens wurden die meisten Microservice-Migrationen der letzten Jahre weit unterhalb der eigentlich sinnvollen Schwelle gestartet, zweitens lassen sich die laufenden Mehrkosten nicht mehr mit „so machen es die Großen“ rechtfertigen, weil die Großen selbst zurückrudern. Dieser Artikel ordnet die Optionen ehrlich ein — klassischer Monolith, Modular Monolith und echte Microservices — und zeigt, wann welcher Ansatz wirklich passt. Für die Einordnung in die Gesamt-Strategie siehe unseren Leitfaden Softwareentwicklung für den Mittelstand.

Die Realität 2026: das Pendel schwingt zurück

Der „Microservices everywhere“-Trend hat zwischen 2015 und 2022 viele Architektur-Entscheidungen geprägt, die heute teuer korrigiert werden. Drei Beobachtungen aus unserer Beratungspraxis fassen die aktuelle Lage zusammen. Erstens: Unternehmen, die unter 30 Entwicklern haben, betreiben Microservice-Landschaften mit erheblichem Overhead — Service-Mesh, Distributed-Tracing, eigene Plattform-Teams — ohne dass die Geschäftslogik diese Komplexität rechtfertigen würde. Zweitens: viele „Microservices“ in der Praxis sind in Wirklichkeit verteilte Monolithen — Services, die zwar über Netzwerk kommunizieren, aber so eng gekoppelt sind, dass jede Änderung mehrere Repositories und mehrere Deployments synchronisieren muss. Drittens: die operativen Kosten verteilter Systeme — Observability, Verfügbarkeit, Konsistenz, Sicherheit zwischen Services — werden in den meisten Business-Cases massiv unterschätzt.

Gleichzeitig hat die Software-Industrie in den letzten Jahren ein präziseres Vokabular entwickelt. Statt der binären Wahl „Monolith oder Microservices“ kennen wir heute mindestens drei klar unterscheidbare Architektur-Stile: den klassisch gewachsenen Monolith, den Modular Monolith nach Domain-Driven-Design-Prinzipien und echte Microservices. Die Entscheidung ist also kein Schwarz-Weiß-Vergleich, sondern eine Reife-Frage. Für die meisten deutschen mittelständischen Unternehmen ist der Modular Monolith heute der sinnvolle Zielzustand — und der bleibt es typischerweise auch über mehrere Jahre.

Der klassische Monolith — Pros und Cons

Der klassische Monolith ist eine Anwendung, die als einzelnes Artefakt deployed wird, intern aber keine erzwungenen Modul-Grenzen kennt. Datenbank-Zugriffe, Geschäftslogik und Präsentationsschicht verlaufen oft kreuz und quer, gewachsen über Jahre. Die Wahrnehmung dieser Architektur ist verzerrt — sie hat reale Stärken, die im Microservice-Hype gerne übersehen wurden.

Aspekt	Stärke	Schwäche
Entwicklungs-Geschwindigkeit am Anfang	Sehr hoch — alle Komponenten im selben Prozess, einfacher Build, ein Repository	Sinkt mit Code-Größe, wenn keine Modul-Grenzen erzwungen werden
Betrieb	Ein Deployment, ein Logfile, ein Health-Check — trivial im Vergleich zu verteilten Systemen	Volldeployment bei jeder Änderung, längere Downtimes bei großen Anwendungen
Transaktions-Konsistenz	ACID-Transaktionen über die gesamte Datenbank, keine verteilte Konsistenz nötig	Datenbank wird zum Engpass bei extremer Last
Onboarding neuer Entwickler	Eine Codebase, ein Setup, ein lokaler Dev-Server	Bei mehreren hunderttausend Zeilen Code unübersichtlich
Refactoring	Compiler oder Type-Checker prüft alle Aufrufstellen synchron	Ohne klare Grenzen entstehen versteckte Abhängigkeiten

Der echte Schwachpunkt des klassisch gewachsenen Monolith ist nicht die Architektur selbst, sondern die Disziplin: ohne erzwungene Modul-Grenzen entsteht über die Jahre eine Spaghetti-Struktur, in der jede Änderung Seiteneffekte an unerwarteter Stelle auslöst. Genau hier setzt der Modular Monolith an.

Modular Monolith — der unterschätzte Sweet-Spot

Ein Modular Monolith ist ein einzelnes deploybares Artefakt — wie ein klassischer Monolith — aber intern strikt in Module aufgeteilt, die nur über definierte Schnittstellen kommunizieren. Die Trennung wird nicht per Goodwill der Entwickler, sondern technisch erzwungen: über Maven- oder Gradle-Module, Go-Packages mit internal-Schutz, .NET-Project-References, oder Architektur-Linter wie ArchUnit oder Dependency-Cruiser. Wer eine Cross-Modul-Abhängigkeit anlegt, die nicht über die definierte API läuft, scheitert im Build, nicht erst im Code-Review.

Zwei Architektur-Stile liefern den passenden konzeptionellen Unterbau für einen Modular Monolith. Erstens die hexagonale Architektur, die Geschäftslogik vom Außenring der Adapter — Datenbank, HTTP, Message-Bus — strikt trennt und damit Domain-Code unabhängig von Infrastruktur testbar macht. Zweitens Domain-Driven Design mit dem zentralen Konzept der Bounded Contexts: jedes Modul ist ein Bounded Context mit eigener Sprache, eigener Datenhoheit und expliziten Schnittstellen zu anderen Kontexten.

Aus unserer Beratungspraxis: in über 80 Prozent der Architektur-Audits bei mittelständischen Mandanten kommen wir zur Empfehlung, statt einer Microservice-Migration zuerst den bestehenden Monolith in einen sauberen Modular Monolith zu überführen. Die Vorteile sind handfest. Die Modul-Grenzen liefern bereits 80 Prozent des Wartbarkeits-Nutzens, den Microservices versprechen — ohne den Betriebsaufwand. Datenbank-Transaktionen bleiben ACID, kein Saga-Pattern nötig. Refactorings sind compiler-gestützt. Die Modul-Struktur ist gleichzeitig ein perfekter Vorbereiter für eine spätere Microservice-Extraktion einzelner besonders skalierungs-kritischer Bounded Contexts — der Strangler-Fig wartet schon, falls er je gebraucht wird.

Microservices — wann wirklich nötig

Microservices haben legitime Anwendungsfälle. Die folgende Liste fasst die Situationen zusammen, in denen die Mehrkosten verteilter Systeme nachweislich gerechtfertigt sind:

• Team-Skalierung über 50 EntwicklerWenn mehr als sieben unabhängige Produkt-Teams parallel an einem System arbeiten, werden Deployment-Konflikte im Monolith spürbar. Microservices ermöglichen unabhängige Release-Zyklen pro Team. Unterhalb dieser Schwelle ist der Vorteil rein theoretisch.
• Unabhängige Skalierungs-BedarfeWenn eine Komponente — etwa Bild-Verarbeitung, Such-Index, KI-Inferenz — eine Größenordnung mehr Compute braucht als der Rest, lohnt es sich, genau diese Komponente als eigenständigen Service auf eigener Infrastruktur zu betreiben. Der Rest kann Monolith bleiben.
• Technologie-Heterogenität als PflichtWenn ein Teil des Systems zwingend in einer anderen Programmiersprache oder Runtime laufen muss — typisch für ML-Modelle oder Hardware-nahe Komponenten — ist ein eigener Service der saubere Weg. Das ist aber ein Fall für einen oder zwei Spezial-Services, nicht für 50.
• Compliance- oder Sicherheits-IsolationWenn ein Subsystem eine strengere Sicherheits-Zone braucht — Zahlungsverkehr, Patientendaten — kann eine harte Netzwerk- und Prozess-Trennung als eigenständiger Service erforderlich sein.
• Akquisition oder Joint VentureWenn ein zugekauftes System integriert werden muss, das technologisch grundverschieden ist, ist eine Service-Grenze oft die pragmatischste Lösung — ohne dass das gesamte System auf Microservices umgestellt werden müsste.

Außerhalb dieser Szenarien ist der Aufwand selten gerechtfertigt. Eine Faustregel aus unserer Praxis: wenn Sie nicht klar benennen können, welcher konkrete geschäftliche Engpass durch Microservices gelöst wird, bauen Sie eine Lösung für ein Problem, das Sie nicht haben.

Service-Mesh und API-Gateway-Overhead

Sobald mehr als eine Handvoll Services im Spiel sind, kommen Service-Mesh und API-Gateway ins Bild. Ein Service-Mesh — Istio, Linkerd oder ähnliches — übernimmt mTLS, Retry-Logik, Traffic-Shaping und Telemetrie zwischen Services. Ein API-Gateway — Kong, Apigee, AWS API Gateway — übernimmt Authentifizierung, Rate-Limiting und Versionierung am Außenrand. Beides ist mächtig, aber teuer in Setup und Betrieb. Ein Istio-Cluster braucht typischerweise eine dedizierte Plattform-Engineer-Stelle, weil die Sidecar-Proxies CPU- und Memory-Overhead pro Pod verursachen und Konfigurations-Fehler subtile Latenz- und Sicherheits-Probleme auslösen können.

Für mittelständische Mandanten unterhalb von 30 Microservices empfehlen wir typischerweise einen leichtgewichtigen Ansatz: kein vollständiges Service-Mesh, sondern ein einfaches API-Gateway am Außenrand und Bibliotheks-gestützte Retry- und mTLS-Logik innerhalb. Wer das Service-Mesh nicht braucht, soll es nicht aufsetzen — der laufende Betrieb ist erheblich.

Datenbank-pro-Service-Problem

Eine der härtesten Konsequenzen echter Microservice-Architektur ist die Datenhoheit pro Service. Das Mantra lautet: jeder Service hat seine eigene Datenbank, andere Services dürfen nicht direkt darauf zugreifen, nur über die API. Das klingt sauber, hat aber drastische Folgen für die Geschäftslogik. Reports, die früher mit einem JOIN über mehrere Tabellen aufgebaut wurden, brauchen jetzt einen Reporting-Service mit eigenem aggregierten Datenmodell, das per Event-Sourcing oder CDC aus den Quell-Services aktualisiert wird. Konsistenz zwischen Services wird vom Datenbank-Problem zum Architektur-Problem.

Wer diese Konsequenz nicht akzeptieren will und Microservices trotzdem auf einer geteilten Datenbank betreibt, baut einen verteilten Monolith — das schlechteste aus beiden Welten. Wir sehen das in Audits regelmäßig und es ist immer ein Refactoring-Großprojekt, das vorne hätte vermieden werden können.

Verteilte Transaktionen: Saga und Outbox

Verteilte Transaktionen über Service-Grenzen hinweg sind das mit Abstand komplexeste Kapitel der Microservice-Praxis. ACID funktioniert nicht über Netzwerk-Grenzen. Zwei Muster haben sich etabliert, beide solide, beide aufwendig.

Das Saga-Pattern zerlegt eine Geschäftstransaktion — etwa „Bestellung anlegen, Zahlung einziehen, Lager reservieren, Versand auslösen“ — in eine Kette lokaler Transaktionen, jede in ihrem eigenen Service. Schlägt ein Schritt fehl, müssen die vorherigen Schritte über Kompensations-Aktionen rückgängig gemacht werden. Saga kann orchestriert sein, mit einem zentralen Saga-Koordinator, oder choreographiert, bei der jeder Service auf Events der anderen reagiert. Beide Varianten sind testtechnisch anspruchsvoll, weil Fehlerfälle und Ordnungs-Probleme im Eventfluss explizit modelliert werden müssen.

Das Outbox-Pattern löst ein verwandtes Problem: wie veröffentliche ich ein Event zuverlässig genau dann, wenn die zugehörige Datenbank-Transaktion erfolgreich war? Die Lösung ist eine Outbox-Tabelle in derselben Datenbank wie die fachlichen Daten. Datenbank-Schreibvorgang und Event-Schreibvorgang erfolgen in einer einzigen Transaktion. Ein separater Relay-Prozess liest neue Outbox-Einträge und schickt sie an den Message-Bus, mit At-Least-Once-Garantie. Das macht Idempotenz auf der Empfänger-Seite zur Pflicht — ein Aspekt, den Teams oft unterschätzen, bis Duplikate in Produktion auftauchen.

Observability-Mehraufwand

In einem Monolith reicht oft ein gutes Logfile und ein einfaches APM-Tool. In einer Microservice-Landschaft brauchen Sie Distributed Tracing — typischerweise OpenTelemetry mit einem Backend wie Jaeger, Tempo oder einer Managed-SaaS-Lösung wie Datadog oder Honeycomb. Eine einzelne Anfrage durchläuft fünf, zehn oder mehr Services, und ohne Traces ist die Fehlersuche bei Latenz-Problemen praktisch unmöglich. Metriken pro Service müssen aggregiert, korreliert und visualisiert werden. Logs müssen zentral gesammelt, durchsuchbar und mit Trace-IDs verknüpft sein.

Realistisch kostet ein solider Observability-Stack für eine 20-Service-Landschaft in Tooling-Lizenzen 30.000 bis 120.000 Euro pro Jahr, dazu eine halbe bis ganze Plattform-Engineer-Stelle für Betrieb und Korrelation. Wer Microservices ohne diese Investition betreibt, fährt blind. Tieferer Vergleich der Frameworks im Cluster-Artikel Kubernetes Mittelstand.

Migration vom Monolith — Strangler-Fig in der Praxis

Wenn die Entscheidung fällt, von einem klassisch gewachsenen Monolith zu einem Modular Monolith oder selektiv zu Microservices zu migrieren, ist der Strangler-Fig-Pattern das robusteste Vorgehen. Der Name kommt von der Würgefeige, die einen Baum umwächst und Stück für Stück ersetzt, ohne dass der ursprüngliche Baum auf einen Schlag fällt. Die Migration läuft in fünf Phasen:

1. Reverse-Proxy einziehen. Ein API-Gateway oder Reverse-Proxy wird vor den bestehenden Monolith gesetzt. Alle Anfragen laufen jetzt durch diesen Proxy, der zunächst alles transparent durchreicht. Das ist die Voraussetzung für selektives Routing in späteren Phasen.
2. Bounded Context identifizieren. Der erste herausgelöste Teil sollte ein klar abgegrenzter Bounded Context sein — typischerweise ein Bereich mit eigener Datenhoheit, klaren Schnittstellen und überschaubarer Größe. Kein Big-Bang, kein Kern-Domain-Modul.
3. Neuen Service parallel bauen. Der neue Service implementiert die Funktionalität des herausgelösten Kontexts, zunächst mit einer eigenen Datenbank, die initial per Sync oder CDC aus dem Monolith versorgt wird.
4. Traffic umleiten. Der Reverse-Proxy leitet schrittweise die zugehörigen Routen auf den neuen Service. Erst Shadow-Traffic zum Vergleich, dann Canary-Releases mit ansteigendem Prozentsatz, dann vollständig.
5. Alt-Code löschen. Der entsprechende Code-Pfad im Monolith wird entfernt, sobald der neue Service stabil läuft. Dieser Schritt wird oft vergessen, ist aber für die Wartbarkeit zentral.

Jede Phase ist jederzeit rückrollbar. Genau das macht Strangler-Fig dem Big-Bang-Rewrite überlegen, der in unserer Beratungspraxis in mindestens zwei Drittel der Fälle scheitert oder massiv über Budget läuft. Detaillierter dazu im Cluster Legacy-Modernisierung.

Conway's Law — der Org-Konflikt

Mel Conway formulierte 1968 die Beobachtung, dass die Architektur eines Systems die Kommunikations-Struktur der Organisation widerspiegelt, die es baut. Vier Jahrzehnte später ist das Gesetz empirisch gut belegt. Für die Monolith-vs-Microservices-Frage hat es eine harte Konsequenz: wenn die Organisation in funktionalen Silos arbeitet — eine Datenbank-Abteilung, eine Frontend-Abteilung, eine Backend-Abteilung — wird sie auch Microservices entlang dieser Schnittstellen bauen. Das Resultat sind technische Services, die fachliche Geschäftslogik über mehrere Teams verteilen. Jede Änderung an einem Geschäftsprozess braucht dann Koordination über Team-Grenzen — Microservices verschlimmern das Problem, statt es zu lösen.

Erfolgreiche Microservice-Architekturen folgen einer anderen Org-Struktur: cross-funktionale Produkt-Teams, die einen Bounded Context vollständig besitzen — Frontend, Backend, Datenbank, Betrieb, Produkt-Verantwortung. Wer Microservices technisch einführen will, ohne diese Org-Transformation mitzudenken, baut systematisch verteilte Monolithen. Die Reihenfolge ist klar: Organisation entlang der Bounded Contexts neu schneiden, dann darüber nachdenken, ob Microservices die richtige technische Umsetzung sind.

Realistischer Kostenvergleich

Die folgende Tabelle zeigt Kosten-Größenordnungen aus unserer Beratungspraxis für ein mittelständisches Szenario: ein Produkt-System mit 20 Entwicklern, deutscher Hosting-Standort, drei Umgebungen, kontinuierlicher Betrieb. Die Zahlen sind als realistische Orientierung gedacht, nicht als Angebot.

Kostenfaktor	Modular Monolith	Microservices (10–20 Services)
Hosting und Infrastruktur pro Jahr	15.000–35.000 €	60.000–150.000 €
Observability-Tooling pro Jahr	3.000–8.000 €	30.000–120.000 €
Plattform-Engineering-Stellenanteil	10–20 % einer Stelle	1–2 Vollzeit-Stellen
Onboarding-Zeit neuer Entwickler	1–2 Wochen produktiv	4–8 Wochen produktiv
Einmal-Kosten Migration	50.000–200.000 €	250.000–1.500.000 €
Deployment-Komplexität	Ein Artefakt, Standard-Pipeline	10–20 Pipelines, Versions-Matrix, Compatibility-Tests

Diese Zahlen bedeuten nicht, dass Microservices grundsätzlich falsch sind. Sie bedeuten, dass die Investition gerechtfertigt sein muss. In einem Unternehmen mit 200 Entwicklern, mehreren Produktlinien und klaren Skalierungs-Engpässen ist die Mehrinvestition ein Bruchteil des erzielten Geschwindigkeits-Gewinns. In einem Unternehmen mit 20 Entwicklern und einem klaren Kern-Produkt ist sie verbrannte Kapazität.

Reepa-Empfehlung: Modular Monolith first

Für etwa 80 Prozent unserer mittelständischen Mandanten lautet die Empfehlung: starten Sie mit einem sauber strukturierten Modular Monolith nach hexagonaler Architektur und Domain-Driven-Design-Prinzipien. Erzwingen Sie Modul-Grenzen technisch, nicht per Konvention. Halten Sie die Datenbank-Schemata pro Modul logisch getrennt — eigene Tabellen-Präfixe oder Schemas in derselben Datenbank — sodass eine spätere Extraktion möglich bleibt. Investieren Sie in einen sauberen Test-Aufbau, der Bounded Contexts unabhängig testbar macht.

Diese Architektur trägt typischerweise über fünf bis zehn Jahre, oft länger. Erst wenn konkrete Skalierungs- oder Team-Topologie-Gründe auftreten — und diese müssen benannt und gemessen sein, nicht antizipiert — wird ein einzelner Bounded Context per Strangler-Fig zum eigenständigen Service extrahiert. Diese gezielte Microservice-Extraktion ist eine völlig andere Operation als eine Big-Bang-Migration und hat eine deutlich höhere Erfolgswahrscheinlichkeit. Für die technische Schnittstellen-Frage zwischen Services oder Modulen siehe unseren Cluster zu API-Design REST vs GraphQL.

Häufige Fragen