TL;DR — standardmäßig modularer Monolith
Die Architekturdebatte der Jahre 2016–2020 — "Monolithen sind tot, Microservices sind die Zukunft" — wurde durch harte betriebliche Erfahrung weitgehend korrigiert. Hier ist die Kurzfassung:
- Standardmäßig modularer Monolith. Saubere Module, durchgesetzte Domänengrenzen, eine einzige Deploy-Pipeline. Das ist der richtige Ausgangspunkt für die überwiegende Mehrheit der Webanwendungen, einschließlich B2B-SaaS, Marktplätze und Enterprise-Portale.
- Services extrahieren, wenn Sie einen konkreten Grund haben. Unterschiedliche Skalierungsprofile, unabhängige Deployment-Rhythmen oder Team-Ownership-Grenzen, die ein Monolith nicht sauber ausdrücken kann. Nicht früher.
- Vollständige Microservices machen erst in großem Maßstab Sinn. Denken Sie an 20+ Ingenieure, 10 Mio.+ Anfragen pro Tag und wirklich divergierende Service-SLAs. Unterhalb dieser Schwelle ist der Overhead eine reine Steuer auf die Velocity Ihres Teams.
- Ein einfacher Monolith ist keine Schande. Shopify, Stack Overflow und Basecamp haben Milliarden von Dollar Umsatz mit gut abgestimmten Monolithen erzielt. Die Architektur ist nur falsch, wenn sie Sie daran hindert, etwas zu tun, das Sie tun müssen.
Die drei Optionen im Überblick
Traditioneller Monolith
Eine einzelne deploybare Anwendung, bei der alle Geschäftslogik, Datenzugriff und Präsentation in einer einzigen Codebasis und einem Prozess leben. Jedes Feature wird gemeinsam ausgeliefert; die Datenbank ist gemeinsam genutzt; Skalierung bedeutet das Ausführen von mehr Kopien der gesamten Anwendung. Die klassische Rails-App, das Django-Projekt oder der Spring-Boot-Service ist ein Monolith.
Modularer Monolith
Immer noch ein einzelnes deployables Binary, aber der Code ist in klar definierte Module unterteilt — jedes mit eigener Domänenlogik, eigenem Datenbankschema-Namespace und eigenem öffentlichen Interface. Module kommunizieren über In-Process-APIs oder Message-Contracts, nicht über HTTP-Aufrufe. Das Ergebnis ist eine Codebasis, die einfach deployt wird, aber so strukturiert ist, dass eine künftige Extraktion möglich ist. Das ist die Architektur, auf die wir bei der Entwicklung von Webanwendungen für unsere Kunden in den USA und der EU als erstes zurückgreifen.
Microservices
Eine Sammlung unabhängig deployabler Services, jeder zuständig für eine enge Domäne, kommunizierend über HTTP oder einen Message-Broker (Kafka, RabbitMQ, SQS). Jeder Service hat seine eigene Datenbank, seine eigene CI/CD-Pipeline und seinen eigenen operationalen Footprint. Richtig umgesetzt, ermöglicht es großen Organisationen, schnell zu liefern, ohne sich gegenseitig zu behindern. Zu früh umgesetzt, ist es ein verteilter Monolith mit allen Nachteilen beider Welten und keinem der Vorteile von einem der beiden.
Was ein moderner Monolith wirklich kann
Das Narrativ, dass "Monolith gleich Legacy" sei, ist ein Marketingartefakt der Kubernetes-Ära. Seien wir präzise in dem, was moderne Monolithen können und was nicht.
Sie skalieren horizontal
Das Ausführen von vier Kopien einer Rails- oder Django-App hinter einem Load Balancer ist horizontale Skalierung. Es funktioniert, bis Ihre Datenbank zum Engpass wird — an welchem Punkt Sie Read Replicas und Connection Pooling hinzufügen, nicht unbedingt einen neuen Service. Stack Overflow verarbeitet Milliarden von Seitenaufrufen auf neun On-Premise-Servern. Der Engpass war nie der Monolith; es war das Fehlen von Caching, Indexierung und Abfrage-Disziplin.
Sie unterstützen schnelle Iteration
Ein Monolith hat eine Deploy-Pipeline. Einen Satz Integrationstests. Einen Ort, an dem man nach einem Bug suchen kann. Für ein Team von 3–15 Ingenieuren ist das ein enormer Koordinationsvorteil. Jedes verteilte System, das Sie hinzufügen, multipliziert die Fehlermodi, die Sie überwachen müssen, und die Rollback-Szenarien, die Sie üben müssen.
Sie unterstützen Compliance-Grenzen
DSGVO-Datenresidenz, HIPAA-Prüfprotokolle und SOC-2-Kontrollen sind innerhalb einer Anwendung einfacher zu implementieren als über ein Netz von Services hinweg durchzusetzen. Ein einzelner Prüfpfad, ein einzelner Secrets-Store, ein einzelner TLS-Terminierungspunkt. Sehen Sie die Muster, die wir in unserem Artikel über den Aufbau von Multi-Tenant-SaaS verwenden — Multi-Tenancy ist innerhalb eines modularen Monolithen vollständig erreichbar.
Wo Monolithen wirklich kämpfen
Es gibt echte Einschränkungen. Wenn Ihr Checkout-Service die 50-fache Last Ihres Reporting-Moduls verarbeiten muss, verschwendet das Skalieren der gesamten App Ressourcen. Wenn Ihre ML-Inferenz-Pipeline völlig andere Laufzeitanforderungen hat (GPU, Python, anderer Deploy-Rhythmus), ist es umständlich, sie im selben Prozess zu halten. Das sind die richtigen Gründe, einen Service zu extrahieren — nicht technische Mode.
Wann Microservices sich wirklich lohnen
Es gibt Szenarien, in denen Microservices die richtige Antwort sind. Hier erfahren Sie, wie Sie sie erkennen.
Wirklich unterschiedliche Skalierungsprofile
Wenn Ihre Produktempfehlungs-Engine während der Spitzenzeiten 1.000 Anfragen pro Sekunde erhält, während Ihre Benutzereinstellungs-API 5 erhält, macht es keinen Sinn, beide zusammen zu skalieren. Sobald Sie diese Divergenz in der Produktion quantifizieren können — nicht in einer Whiteboard-Session — amortisiert sich die Service-Extraktion von selbst. Verwandt: Sehen Sie den Enterprise-KI-Agenten-Stack 2026 für die Erklärung, warum inference-intensive Workloads oft eine Isolation aus genau diesem Grund rechtfertigen.
Unabhängige Deployment-Rhythmen
Wenn separate Produktteams mehrmals täglich ohne Koordination deployen müssen, wird eine einzige Deploy-Pipeline zum Engpass. Das ist Amazons ursprüngliche Motivation für Microservices — nicht Performance, sondern organisatorische Velocity. Wenn Ihr Analytics-Team und Ihr Billing-Team aufeinander warten müssen, bis der Code des anderen stabil ist, bevor ein Release erfolgt, schafft die Architektur ein menschliches Koordinationsproblem, das eine Service-Grenze lösen würde.
Isolierte Fehlerdomänen
Ein katastrophaler Bug in einem Monolithen bringt die gesamte Anwendung zum Erliegen. In einer Microservices-Architektur muss ein Bug in Ihrem Benachrichtigungs-Service nicht den Checkout zum Stillstand bringen. Circuit Breaker, Bulkheads und graceful Degradation sind Muster, die nur dann sinnvoll sind, wenn Sie Service-Grenzen haben, an denen sie durchgesetzt werden können. Für umsatzstarke Flows — Zahlungen, Core-API, Authentifizierung — ist die Isolationsgarantie den operativen Aufwand wert.
Regulatorische und Datenresidenz-Grenzen
Ein US-Unternehmen, das EU-Kunden unter der DSGVO bedient, benötigt möglicherweise wirklich EU-residente Daten, die in einem separat deployt und auditierten Service verarbeitet werden, nicht nur ein Konfigurations-Flag in einer gemeinsamen App. Gleiches gilt für die PCI-DSS-Scope-Isolation — Karteninhaberdaten, die in einem separaten Service mit eigener Netzwerkgrenze verarbeitet werden, sind architektonisch sauberer als die Verkleinerung der Angriffsfläche eines Monolithen.
Kosten, Teamgröße und Betriebsaufwand
Microservices sind nicht kostenlos. Jeder Service, den Sie hinzufügen, multipliziert die Infrastruktur- und Personalkosten. Hier ist eine ehrliche Abrechnung.
Infrastrukturkosten
Jeder Service benötigt sein eigenes: Compute (Container, Lambda oder VM), Datenbank oder Datenbank-Namespace, Secrets-Manager-Integration, Load-Balancer- oder API-Gateway-Routing-Regel, Log-Aggregations-Pipeline-Eintrag und Health-Check-Monitor. Bei einer Zehn-Service-Architektur betreiben Sie zehn von jedem dieser Elemente. Auf AWS oder GCP kostet ein modularer Monolith oft 60–80% weniger an monatlicher Infrastruktur als ein äquivalentes Microservices-Mesh bei gleichem Traffic.
Observability-Kosten
Ein Monolith schlägt fehl mit einem Stack-Trace in einem einzigen Log-Stream. Ein verteiltes System schlägt fehl mit partiellen Traces über fünf Services, zwei asynchrone Queues und eine Caching-Schicht verteilt. Verteiltes Tracing (Jaeger, Tempo, AWS X-Ray), strukturierte Log-Aggregation (Loki, Datadog, CloudWatch) und Service-Health-Dashboards sind obligatorisch, nicht optional. Veranschlagen Sie einen dedizierten Platform-Ingenieur plus 2.000–8.000 USD/Monat für SaaS-Tooling für ein Team, das 10+ Services betreibt.
Anforderungen an die Teamgröße
Amazons Two-Pizza-Regel (6–10 Ingenieure pro Service) ist das operative Minimum, damit jeder Service ohne ständigen Kontextwechsel gewartet werden kann. Unterhalb von 20–30 Ingenieuren insgesamt bedeuten Microservices, dass jeder Ingenieur mehrere Services betreut — genau der Koordinations-Overhead, den die Architektur eigentlich beseitigen sollte. Sehen Sie auch das SaaS-Churn-Reduction-Playbook dafür, wie Architekturentscheidungen vorgelagert die Produktzuverlässigkeit beeinflussen, die die Kundenbindung antreibt.
| Dimension | Monolith | Modularer Monolith | Microservices |
|---|---|---|---|
| Deploy-Komplexität | Niedrig | Niedrig | Hoch |
| Infrastrukturkosten (gleicher Traffic) | Am niedrigsten | Am niedrigsten | 2–5x höher |
| Observability-Overhead | Minimal | Minimal | Erheblich |
| Horizontale Skalierbarkeit | Grobgranular | Grobgranular | Feingranular |
| Unabhängige Team-Deploys | Nein | Teilweise | Ja |
| Min. Team für guten Betrieb | 3–5 Ingenieure | 5–15 Ingenieure | 20+ Ingenieure |
| Zeit bis zum ersten Produktions-Deploy | 1–2 Wochen | 1–3 Wochen | 4–8 Wochen |
Eine Web-App richtig skalieren
Bevor Sie eine Architektur basierend auf zukünftiger Skalierung wählen, die Sie noch nicht haben, wenden Sie diese Skalierungshebel der Reihe nach an — die meisten Anwendungen müssen nie über Schritt drei hinausgehen.
1. Vertikale Skalierung und Abfrageoptimierung
Verdoppeln Sie Ihre Datenbankinstanzgröße. Fügen Sie einen Index zur langsamen Abfrage hinzu. Aktivieren Sie Connection Pooling (PgBouncer, RDS Proxy). Das ist kostenlose oder nahezu kostenlose Ingenieurarbeit und kauft häufig 5–10x Kapazitätspuffer. Die meisten Anwendungen, die "Microservices für die Skalierung brauchen", brauchen tatsächlich einen Datenbankindex und einen Redis-Cache.
2. Horizontale Anwendungsskalierung
Führen Sie mehrere Instanzen Ihres Monolithen hinter einem Load Balancer aus. Fügen Sie Read Replicas für leseintensive Workloads hinzu. Verwenden Sie ein CDN, um statische Assets und gecachte API-Antworten auszulagern. Ein einzelner Rails- oder Node.js-Prozess mit 4 vCPUs verarbeitet ~500 Anfragen/Sekunde. Acht Instanzen hinter einem Load Balancer verarbeiten 4.000. Sie erreichen diese Grenze nur langsam.
3. Caching und asynchrones Queuing
Redis oder Memcached vor Ihren heißen Lesepfaden. Eine Background-Job-Queue (Sidekiq, Celery, Bull) für alles, was nicht synchron sein muss — E-Mails, Webhooks, Berichtserstellung, Drittanbieter-API-Aufrufe. Das Auslagern asynchroner Arbeit eliminiert eine Klasse von langsamer Request-Tail-Latenz, die Ihr p95 schlecht aussehen lässt, ohne eine eigentliche Architekturänderung.
4. Einen Service nach dem anderen extrahieren
Wenn ein spezifischer Hot Path wirklich ein Bottleneck ist und die oben genannten Schritte ausgeschöpft sind, extrahieren Sie diesen Service mit dem Strangler-Fig-Pattern. Leiten Sie neuen Traffic an den Service weiter, während der Monolith den Rest verarbeitet. Migrieren Sie schrittweise. Versuchen Sie keine Big-Bang-Umschreibung vom Monolithen zu Microservices — die Fehlerrate ist hoch und die Kosten sind enorm.
Entscheidungsmatrix
Verwenden Sie diese Matrix, wenn Sie die Architekturentscheidung treffen. Bewerten Sie jede Zeile für Ihre aktuelle Situation — nicht für das Unternehmen, das Sie in drei Jahren sein möchten.
| Kriterium | Modularen Monolithen wählen, wenn … | Microservices in Betracht ziehen, wenn … |
|---|---|---|
| Teamgröße | Unter 20 Ingenieure | 20+ Ingenieure über mehrere Produkt-Squads |
| Traffic-Muster | Einheitlich oder heute mit geringem Volumen | Gemessene, divergierende Spitzenlast pro Domäne |
| Deploy-Rhythmus | Ein oder zwei Teams, koordinierte Releases | Mehrere Teams, unabhängige Rhythmen erforderlich |
| Compliance-Isolation | Standard-DSGVO/SOC-2 in einer App handhabbar | PCI-DSS-Karteninhaberschutz oder strenge Datenresidenz |
| DevOps-Reife | Kein dedizierter Platform-Ingenieur | Platform-/SRE-Team bereits vorhanden |
| Technologie-Mix | Eine primäre Sprache/Laufzeit | Echter Bedarf an gemischten Laufzeiten (z.B. ML-GPU-Service) |
| Fehlertoleranzanforderung | Vollständige Ausfallzeit bei seltenen Vorfällen akzeptabel | Partielle Degradierung erforderlich (Checkout muss Analytics-Ausfall überleben) |
FAQ
Sollte ein Start-up Microservices verwenden?
Fast nie am Anfang. Microservices multiplizieren die operative Angriffsfläche — Service Discovery, verteiltes Tracing, unabhängige CI/CD-Pipelines und ein Team, das groß genug ist, um jeden Service zu betreuen. Der Engpass eines Start-ups ist das schnelle Liefern von Produkten und das schnelle Lernen, nicht Infrastrukturflexibilität. Starten Sie mit einem modularen Monolithen; extrahieren Sie Services, wenn eine konkrete Skalierungs- oder Ownership-Grenze Sie dazu zwingt.
Was ist ein modularer Monolith?
Ein modularer Monolith ist eine einzelne deploybare Anwendung, intern in klar definierte, lose gekoppelte Module unterteilt — jedes mit eigener Domänenlogik, Datenbankschema-Namespace und öffentlicher API-Oberfläche. Er wird als ein Prozess deployt, ist aber so strukturiert, dass einzelne Module später mit minimalem Refactoring in separate Services extrahiert werden können. Er ist der ideale Kompromiss für die meisten Teams mit bis zu 50 Ingenieuren.
Wann zahlen sich Microservices aus?
Microservices zahlen sich aus, wenn: (1) verschiedene Teile des Systems wirklich unterschiedliche Skalierungsprofile haben — Checkout verarbeitet die 10-fache Last von Admin; (2) unabhängige Teams deployen müssen, ohne Releases zu koordinieren; (3) ein bestimmter Service einen anderen Technologie-Stack, ein anderes SLA oder eine andere Compliance-Grenze erfordert. Wenn keine dieser Bedingungen heute zutrifft, ist der Overhead von Microservices reiner Kostenfaktor.
Sind Microservices skalierbarer als ein Monolith?
Nicht automatisch. Ein gut abgestimmter Monolith auf moderner Cloud-Infrastruktur verarbeitet mit horizontaler Skalierung, Connection Pooling und Read Replicas Millionen von Anfragen pro Tag. Microservices ermöglichen eine feingranulare Skalierung von Hot Paths — aber dieser Vorteil materialisiert sich nur, wenn verschiedene Services wirklich unterschiedliche Traffic-Muster haben. Viele Teams fügen Microservices-Komplexität hinzu, bevor sie den Traffic haben, der sie rechtfertigen würde.
Wie groß sollte das Team sein, um Microservices zu betreiben?
Amazons Two-Pizza-Regel ist ein nützlicher Leitfaden: Jeder Service sollte von einem Team aus 6–10 Ingenieuren betreut werden können. In der Praxis benötigen Sie mindestens einen dedizierten DevOps- oder Platform-Ingenieur, SRE-Abdeckung, Observability-Tooling und genug Entwickler, um jeden Service ohne ständigen Kontextwechsel zu warten. Unterhalb von 20–30 Ingenieuren insgesamt erzeugen Microservices in der Regel mehr Koordinations-Overhead als sie beseitigen.
Kann ich später von einem Monolithen zu Microservices migrieren?
Ja — und das ist der empfohlene Weg. Bauen Sie von Anfang an einen modularen Monolithen mit sauberen Domänengrenzen auf, und das spätere Extrahieren eines Services ist ein überschaubarer Aufwand: Verschieben Sie den Code eines Moduls, teilen Sie seine Datenbanktabellen auf und fügen Sie einen API-Vertrag hinzu. Das Strangler-Fig-Pattern — das schrittweise Weiterleiten von Traffic an einen neuen Service, während der Monolith den Rest verarbeitet — ist für diese Migration bewährt. Entwerfen Sie nicht am ersten Tag für Microservices, es sei denn, Sie haben bereits das Team und den Traffic, der dies erfordert.
Zuletzt aktualisiert am 4. Juni 2026. Architekturempfehlungen basieren auf Produktionsprojekten für US- und EU-Kunden zwischen 2022 und 2026. Kostenzahlen sind Schätzungen; tatsächliche Infrastrukturausgaben variieren je nach Cloud-Anbieter, Region und Traffic-Muster.
