Monolith vs. Micro Services – Back to the future with modular monolith

Anmerkung: Dieser Blogpost wurde für das Modul Enterprise IT (113601a) verfasst.

Einleitung:

In den vergangen Jahren war die Microservice-Architektur in vielen Unternehmen fast alternativlos. Die grundlegende Idee von Microservices ist es, Anwendungen in kleine, unabhängige Dienste zu zerlegen, welche separat entwickelt, skaliert und deployed werden können. Dieser Ansatz soll flexible Technologieentscheidungen, unabhängige Teamarbeit in den unterschiedlichen Services und eine gezielte Skalierung einzelner Komponenten ermöglichen.

In den letzten paar Jahren hat sich dieses Bild allerdings verändert. Firmen, die ursprünglich Treiber der Umstellung auf Microservice-Architekturen waren, gehen jetzt teilweise zu monolithischen Systemen zurück. So hat Amazon im Jahr 2023 in einem Blog veröffentlicht, in welchem sie erklären, dass sie bei Amazon Prime Video jetzt teilweise wieder auf monolithische Systeme beim Monitoring setzen und so bei diesem Service 90 % der Kosten einsparen konnten. [1][3]

Es scheint also, als würden Microservices nicht nur Vorteile bringen. Sie erhöhen die Komplexität von Betrieb, Kommunikation und Datenkonsistenz deutlich. [2]

Daher erlebt ein scheinbar überholter Ansatz derzeit eine Renaissance:
der modulare Monolith

Monolithen vs. Microservices:

Klassische monolithische Architektur:

Die monolithische Architektur ist der traditionelle Ansatz der Softwareentwicklung. Die Idee ist, die gesamte Applikation als einzelne, in sich selbst geschlossene Einheit zu entwickeln. Dabei wird die Applikation in einer einzigen Codebase mit einem bestimmten Technologie-Stack umgesetzt. [2]

Die Codebase führt dabei alle Geschäftsfunktionen einer Applikation aus. Dabei wird die Anwendung in folgende Komponenten unterteilt:

Die einzelnen Schichten eines Monolithen sind architektonisch voneinander getrennt, jedoch nicht physisch verteilt. Daher wird die gesamte Anwendung als eine gemeinsame Einheit deployt.

• Das Nutzer-Interface beschreibt die Darstellung und Interaktion mit dem Endnutzer. Es umfasst alle Elemente der Benutzeroberfläche sowie die Verarbeitung eingehender Anfragen [5].
• Der Business-Layer bildet den Kern der Applikation und enthält die zentrale Fach- und Geschäftslogik.
• Der Data-Interface-Layer ist für den Zugriff auf die Datenbank verantwortlich und übernimmt das Mapping zwischen Domänenobjekten und Datenbanktabellen.
• In monolithischen Systemen wird als Datenbank häufig ein relationales Datenbankmanagementsystem eingesetzt. Dieses organisiert Daten in Tabellen mit Zeilen und Spalten, die über Beziehungen miteinander verknüpft sind [5].

Aus dieser Architektur ergeben sich mehrere Vorteile. Anwendungen mit einer einzigen Codebasis sind in der Regel einfacher zu entwickeln, zu deployen und zu warten. Auch das Debugging gestaltet sich durch die in sich geschlossene Struktur übersichtlicher, und End-to-End-Tests können über zentrale Logging-Mechanismen durchgeführt werden. Darüber hinaus kann die geschlossene Architektur monolithischer Systeme die Angriffsfläche gegenüber externen Cyberbedrohungen reduzieren, da weniger Schnittstellen nach außen bestehen [5].

Allerdings hat die Architektur auch Nachteile. Die Skalierung eines monolithischen Systems ist erschwert, da immer die gesamte Anwendungseinheit skaliert werden muss. Fehler in einzelnen Komponenten können potenziell das gesamte System beeinträchtigen. Zudem ist die Einführung neuer Technologien aufwendig, da Änderungen häufig große Teile der Codebasis betreffen. Mit wachsender Codebasis können sich außerdem Entwicklungs- und Release Zyklen verlängern [2].

Microservice-Architektur:

Ein anderes Architekturmodell ist die Microservice-Architektur. Im Gegensatz zu monolithischen Systemen wird die Applikation hier in kleinere, unabhängige Services unterteilt. Jeder einzelne Microservice ist eine eigene Einheit, welche einen bestimmten Geschäftsprozess ausführt.

Die einzelnen Services sind dabei so designt, dass sie individuell von Teams entwickelt, bereitgestellt und skaliert werden können. [2] Die einzelnen Services werden dann mit einer in der Makroarchitektur festgelegten definierten Schnittstelle versehen, wodurch sie von außen aufrufbar werden [7]. Die Schnittstelle nutzt dabei standardisierte Protokolle wie z.B. REST oder MOM.

Die Services können durch ihre lose Kopplung und die fest definierte Schnittstelle in unterschiedlichen Programmiersprachen und Frameworks entwickelt werden [2]. Diese Entscheidungen werden in der Mikroarchitektur der einzelnen Services festgelegt.

Eine vereinfachte Microservice-Architektur besteht dabei aus folgenden Komponenten:

Der Client ist hier der Einstiegspunkt in das System. Es kann sich dabei zum Beispiel um einen Webbrowser handeln. Der Client sendet jetzt Anfragen an die jeweiligen Services und erhält die verarbeiteten Ergebnisse zurück. Hier wird wird häufig ein API-Gateway zwischen Client und Services eingesetzt. Das API-Gateway dient als zentrale Zugriffsschicht und übernimmt unter anderem Routing, Authentifizierung sowie auch die Lastverteilung auf mehrere Service-Instanzen. Die einzelnen Services sind hier die Microservices, welche die konkreten Geschäftsprozesse implementieren.

Die Kommunikation läuft dann, wie bereits erwähnt z. B. über REST. Ein weiteres zentrales Prinzip von Microservices ist Database per Service. Das bedeutet, dass jeder Microservice seine eigene Datenbank besitzt und so die vollständige Kontrolle über die jeweiligen Datenmodelle hat. Mit diesem Prinzip wird verhindert, dass von anderen Services auf die Daten zugegriffen wird. [8]

Dabei ergeben sich bei Microservices auch wieder Vor- und Nachteile:

Vorteile:

• Gute Skalierbarkeit: Falls ein einzelner Microservice eine höhere Nutzung hat, kann dieser einzeln multipliziert werden, ohne die anderen Services auch skalieren zu müssen. [5]
• Bessere Fehlertoleranz: Jeder Microservice wird einzeln betrieben. Dadurch wird die Gefahr das die ganze Applikation nicht mehr läuft, wenn ein Fehler in einem einzelnen Service auftritt, minimiert.
• Schnellere Entwicklungszyklen: Anders als bei klassischen Monolithen kann Jeder Microservice für sich entwickelt und die Releases durch CI/CD-Prozesse automatisiert werden. [5]
• Technologische Flexibilität: Durch die Aufteilung in unabhängige Services, kann jeder Microservice verschiedene Technologien Nutzen, sofern sich an die Vorgaben für die Schnittstelle gehalten wird. [20]

Nachteile:

• Höhere Systemkomplexität: Microservices verlagern Komplexität der Applikation in Kommunikation, Schnittstellen und Betrieb verteilter Systeme.
• Schwierigere Tests: Die Verbindungen und Abhängigkeiten zwischen den Services müssen getestet werden, was bei den verteilten Systemen aufwendiger ist.
• Erhöhte Latenz: Wenn ein Microservice skaliert wird, erhöht sich die Menge der Daten die zwischen den Services orchestriert werden muss stark. Hierdurch entsteht ein großer Kommunikationsoverhead, den man bei monolithischen Systemen nicht hat. [5]
• Sicherheitsrisiken: Da die Kommunikation zwischen den einzelnen Services über ein API-Gateway funktioniert, entsteht ein Sicherheitsrisiko, falls das Gateway eine Sicherheitslücke hat [5].
• Kosten: Oft entstehen bei Microservices schnell hohe Kosten durch einen erhöhten Ressourcenverbrauch bei Netzwerk- und Rechenleistung

Modulare Monolithen

Damit zeigt sich, dass weder monolithische Architekturen noch Microservices in allen Szenarien überlegen sind.
Während Monolithen durch Einfachheit und geringe Betriebs-Komplexität überzeugen, bieten Microservices Vorteile hinsichtlich Skalierbarkeit und Entkopplung.

In der Praxis entsteht daraus der Bedarf nach einem Architekturansatz, der die Vorteile von Microservices mit der Einfachheit monolithischer Systeme kombiniert.

Genau hier setzt das Konzept des modularen Monolithen an.
Ein modularer Monolith ist ein Architekturpattern, welches darauf abzielt, eine einzelne Deployment-Einheit bereitzustellen, welche aber klar abgegrenzte, lose gekoppelte Module enthält. Jedes einzelne dieser Module ist, ähnlich wie bei Microservice-Architekturen dabei für jeweils eine fachliche Verantwortung zuständig. [11]

Im Gegensatz zu klassischen Monolithen werden diese Grenzen architektonisch klar durchgesetzt. Jedes Modul kapselt seine eigene Geschäftslogik und kommuniziert über fest definierte Schnittstellen. [10]

Damit kombiniert ein modularer Monolith die Einfachheit eines Monolithen mit der Struktur von serviceorientierten Architekturen, aber ohne die zusätzliche Komplexität verteilter Systeme.
Dabei sieht eine mögliche Architektur eines modularen Monolithen so aus:

Die Clients greifen wieder über ein API-Gateway auf die Applikation zu. Dabei leitet das Gateway die Anfragen der Clients an die entsprechenden Module weiter. Jedes Modul kapselt die Geschäftslogik und den Datenzugriff und kommuniziert ausschließlich über eine definierte Schnittstelle mit den anderen Modulen.
Gleichzeitig laufen alle Module im selben Prozess und innerhalb derselben Codebasis, wodurch keine Netzwerkkommunikation notwendig ist und die Komplexität deutlich geringer bleibt als bei verteilten Systemen. [11]

Der Monolith nutzt eine gemeinsame Datenbasis, allerdings enthält die Datenbasis individuelle Schemata zu den einzelnen Modulen. [11] So wird dafür gesorgt, dass Module nicht direkt auf fremde Daten zugreifen, sondern ausschließlich über die Schnittstellen interagieren.

Dabei bieten modulare Monolithen auch wieder Vor- und Nachteile:

Vorteile:

• Vereinfachte Entwicklung: Durch klar abgegrenzte Module mit definierten Verantwortlichkeiten können Entwickler an einzelnen Funktionsbereichen unabhängig arbeiten, wodurch Entwicklungszyklen beschleunigt werden können.
• Einfacherer Übergang zu Microservice: Da die einzelnen Komponenten bereits als Module mit fest definierten Schnittstellen existieren, ist es einfacher, diese wenn nötig in Microservices umzuwandeln. [14]
• Module können innerhalb eines modularen Monolithen gemeinsame Ressourcen wie Datenbanken, Caching-Mechanismen oder Infrastruktur nutzen. Dies reduziert Redundanzen, senkt den Betriebsaufwand und kann zu einer effizienteren Ressourcennutzung führen. [12]
• Die Kommunikation der einzelnen Module erfolgt innerhalb des selben Prozesses, daher ist die Performance meistens besser, wie bei Microservice-Architekturen. [14]

Nachteile:

• Trotz modularer Struktur bleibt die Unabhängigkeit der Module eingeschränkt, die Applikation wird außerdem weiterhin als ein einzelnes Package deployed. [14]
• Die Entwickler müssen aktiv daran mitarbeiten, die Regeln des modularen Monolithen einzuhalten und keine Direktzugriffe auf andere Module durchzuführen, da man architektonisch sonst schnell wieder bei einem klassischen Monolithen landet. [14]
• Die Kommunikation zwischen Modulen kann zusätzliche Komplexität verursachen.
  Hierfür sind klar definierte Schnittstellen erforderlich, um lose Kopplung zu gewährleisten. [12]

Insgesamt stellt der modulare Monolith damit einen Kompromiss zwischen Einfachheit und Skalierbarkeit dar, der insbesondere für mittelgroße Systeme eine praktikable Alternative zu vollständig verteilten Architekturen bieten kann.

Derzeitige Trends:

In den letzten Jahren lässt sich in der Softwarearchitektur ein deutlicher Wandel beobachten. Während Microservices lange als die dominierende Architektur galten, zeigen aktuelle Studien einen zunehmenden Strom zurück zu weniger verteilten Systemen. So ergab eine Industrieanalyse der CNCF aus dem Jahr 2025, dass 42 % der Organisationen, welche initial ihre Codebasis zu Microservices adaptiert haben, zumindest einen Teil ihrer Services wieder zurück in größere Deployment-Einheiten umwandeln. Die in der Studie genannten primären Gründe für diesen Wandel waren Debugging-Komplexität, operativer Overhead und höhere Netzwerk-Latenzen. [13]

Ein weiteres Beispiel lässt sich in einem Artikel eines Startups nachvollziehen. Das Startup hat ihre Microservice-Architektur in eine monolithische Architektur umgewandelt und veröffentlicht Metriken, wie dieser Schritt sich auf das Startup ausgewirkt hat. [15]

• Die Antwortzeit der Applikation ging von 1,2 Sekunden auf 89 Millisekunden.
• Die AWS-Rechnung reduzierte sich von 18.000$ pro Monat auf 2400$ pro Monat.
• Die Deployment-Dauer reduzierte sich von 45 auf 6 Minuten.

Aber auch große Firmen weichen von einer strikten Microservice-Architektur ab. Wie initial erwähnt setzt Amazon bei einem Teil von Amazon Prime Video auch nicht mehr auf Microservices. Der betreffende Dienst wurde von Amazon wieder in einen einzelnen Prozess überführt. Dadurch entfielen kostenintensive Orchestrierungs- und Speichermechanismen mit Amazons S3-Storage, während Daten direkt im Arbeitsspeicher zwischen Komponenten übertragen werden konnten. Dies führte zu einer deutlichen Verbesserung der Skalierbarkeit sowie zu erheblichen Kosteneinsparungen von rund 90 %. [16]

Andere Firmen wie Shopify setzen auf modulare Monolithen, um einerseits die Vorteile von Monolithen und andererseits die Modularität von Microservices zusammenzuführen. [18]
Große Frameworks wie Spring bieten mittlerweile Hilfsmittel an, um modulare Monolithen einfach zu bauen. So ist Spring Monolith ein Projekt von Spring, welches sich gut zum Bauen von Applikationen als modularer Monolith eignet. [19]

Gleichzeitig behalten Microservices insbesondere bei großen, global skalierenden Technologieunternehmen weiterhin eine zentrale Bedeutung. So basiert die Streaming-Plattform von Netflix auf einer hochgradig verteilten Architektur mit hunderten bis tausenden voneinander unabhängigen Microservices, die gemeinsam die Bereitstellung von Videoinhalten ermöglichen. Diese Struktur erlaubt es Netflix, einzelne Funktionen gezielt zu skalieren und unabhängig weiterzuentwickeln. [17]

Und auch im Umfeld von Amazon werden Microservices weiterhin aktiv eingesetzt, da sie eine unabhängige Entwicklung, Bereitstellung und Skalierung einzelner Dienste ermöglichen.

Fazit

Es zeigt sich, dass weder monolithische noch Microservice-Architekturen überlegen sind. Monolithische Systeme zeichnen sich durch ihre geringe Betriebs- und Kommunikationskomplexität aus, während Microservices bei Skalierung und Entkopplung Vorteile liefern.

Aktuelle Entwicklungen zeigen, dass die Komplexität und Kosten verteilter Systeme gerade von kleineren Projekten stark unterschätzt wurden. Immer mehr Microservice-Architekturen werden zurück zu größeren monolithischen Systemen umgewandelt. Konkrete Praxisbeispiele mit großen Kosteneinsparungen zeigen, dass Architekturentscheidungen mittlerweile mehr kontext- und wirtschaftsgetrieben getroffen werden. [16]

Der modulare Monolith schließt hier eine Lücke als balancierter Architekturansatz zwischen Microservice und klassischem Monolith. Er bietet die Möglichkeit einer klaren fachlichen Strukturierung und Wartbarkeit innerhalb einer Deployment-Einheit. Gleichzeitig bietet er die Option, bei stark wachsender Komplexität einzelne Module in Richtung Microservices umzuwandeln.

Insgesamt lässt sich sagen, dass es keine allgemein beste Architektur gibt. Die Entscheidung für Monolith, modularen Monolith oder Microservices richtet sich vor allem nach den Anforderungen an Skalierung, Organisation, Kosten und Systemkomplexität.

Quellen

[1] E. Gregory, “What to think about when you think about microservices”. Online verfügbar: https://www.mirantis.com/blog/what-to-think-about-when-you-think-about-microservices Zugriff am:
13.02.2026

[2] A. Mika, “Monolith Architecture vs. Microservices”. Online verfügbar:
https://www.ramotion.com/blog/monolithic-architecture-vs-microservice-architecture Zugriff am:
14.02.2026

[3] M. Kolny, “Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%”. Online verfügbar:
https://web.archive.org/web/20240223075245/https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90 Zugriff am: 14.02.2026

[4] A. Levcovitz, R. Terra, M. T. Valente, “Towards a Technique for Extracting Microservices
from Monolithic Enterprise Systems”. Online verfügbar: https://arxiv.org/pdf/1605.03175 Zugriff am: 14.02.2026

[5] P. Powell, I. Smalley, “Monolithische Architektur vs. Microservice: Was funktioniert für Sie am besten?”. Online verfügbar: https://www.ibm.com/de-de/think/topics/monolithic-vs-microservices Zugriff am 14.02.2026

[6] ByteByteGo, “Monolith vs Microservices vs Modular Monoliths: What’s the Right Choice”. Online verfügbar:
https://blog.bytebytego.com/p/monolith-vs-microservices-vs-modular Zugriff am 14.02.2026 (Nur Free Teil für die Adaption der Grafiken)

[7] M. Domogalla, “software-architektur.tv: Makro-Architektur – Prioritäten und Überblick”. Online verfügbar:
https://www.heise.de/news/software-architektur-tv-Makro-Architektur-Prioritaeten-und-Ueberblick-6281271.html Zugriff am 14.02.2026

[8] AWS Docs, “Database-per-service Muster”. Online verfügbar: https://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-data-persistence/database-per-service.html Zugriff am 14.02.2026

[9] R. Su, X. Li, “Modular Monolith: Is This the Trend in Software Architecture?”. Zusammenfassung Online verfügbar: https://www.emergentmind.com/papers/2401.11867 Zugriff am 15.02.2026

[10] B. Koya, “The Modular Monolith Revolution: Enterprise Grade Architecture-Part I Theory” Online verfügbar:
https://medium.com/%40bhargavkoya56/the-modular-monolith-revolution-enterprise-grade-architecture-part-i-theory-b3705ca70a5f Zugriff am 15.02.2026

[11] Bytecraftlabs, “Modular Monolith Architecture”. Online verfügbar: https://bytecraftlabs.com/modular-monolith-architecture/ Zugriff am 15.02.2026

[12] D. Chubryk, “Developing Modular Monolith vs. Traditional Monolith in Software Engineering, pros and cons”. Online verfügbar: https://dev.to/flashblack/developing-modular-monolith-vs-traditional-monolith-in-software-engineering-pros-and-cons-p61 Zugriff am 19.02.2026

[13] E. Drosopoulou, “Microservices vs Monoliths in 2026: When Each Architecture Wins”. Online verfügbar: https://www.javacodegeeks.com/2025/12/microservices-vs-monoliths-in-2026-when-each-architecture-wins.html
Zugriff am 19.02.2026

[14] M. Santilio, “Monolith, Modular Monolith, and Microservices: A Comparison”. Online verfügbar:
https://dev.to/mikaelsantilio/monolith-modular-monolith-and-microservices-a-comparison-196e
Zugriff am 19.02.2026

[15] Medium, “I Rewrote Our Microservices in a Monolith. Performance Went Up 10x.” Online verfügbar:
https://medium.com/lets-code-future/i-rewrote-our-microservices-in-a-monolith-performance-went-up-10x-36011814550e
Zugriff am 19.02.2026

[16] Byteiota, “Microservices Consolidation: 42% Return to Monoliths”. Online verfügbar:
https://byteiota.com/microservices-consolidation-42-return-to-monoliths/
Zugriff am 19.02.2026

[17] GeeksForGeeks, “How many Microservices are there in Netflix?”. Online verfügbar: https://www.geeksforgeeks.org/system-design/how-many-microservices-are-there-in-netflix/
Zugriff am 19.02.2026

[18] Shopify, “Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity”. Online verfügbar:
https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
Zugriff am 19.02.2026

[19] H. R. Sharifi, “Introduction to Spring Modulith”. Online verfügbar:
https://www.baeldung.com/spring-modulith
Zugriff am 19.02.2026

[20] S. Susnjara, I. Smalley, “Vorteile und Nachteile von Microservices”. Online verfügbar:
https://www.ibm.com/de-de/think/insights/microservices-advantages-disadvantages
Zugriff am 19.02.2026

[21] M. Schwab “Microservices — Grundlagen und Technologien von verteilter Architektur”. Online verfügbar:
https://www.hosteurope.de/blog/microservices-grundlagen-und-technologien-von-verteilter-architektur
Zugriff am 19.02.2026