42 % der Teams bereuen Microservices: Warum wir modulare Monolithen für MVPs bauen

Microservices haben die Architekturdebatte um 2018 gewonnen. Jeder Konferenzvortrag, jeder Blogpost, jede „How we scaled"-Story sagte dasselbe: aufteilen, unabhängig deployen, horizontal skalieren. Netflix macht's. Uber macht's. Ihr solltet auch.

Dann kam die Realität.

Eine CNCF-Umfrage 2025 ergab, dass 42 % der Organisationen, die Microservices eingeführt haben, Services wieder zusammengelegt haben. Gartner berichtet, dass 60 % der Teams die Entscheidung bei kleinen bis mittleren Anwendungen bereuen. Amazon Prime Video hat Infrastrukturkosten um 90 % gesenkt, indem sie von Microservices zurück zum Monolithen gewechselt sind.

Wir bauen MVPs für unseren Lebensunterhalt. Wir haben noch nie eins als Microservices gebaut. Hier ist der Grund.

Die Komplexitätssteuer

Schauen wir uns an, was Microservices ein kleines Team tatsächlich kosten:

Bereich	Monolith	Microservices
Deployment	1 Pipeline, 1 Ziel	5–15 Pipelines, 5–15 Ziele
Lokale Entwicklung	`docker compose up`	8 Services + Service-Mesh-Simulator
Debugging	Ein Log-Stream, ein Debugger	Distributed Tracing, Log-Aggregation
DB-Migrationen	Ein Schema, eine Migration	Pro-Service-Schemas, Cross-Service-Konsistenz
API-Änderungen	Refactor + kompilieren	Contract-Versionierung, Abwärtskompatibilität
Testing	Integrationstests auf einen Prozess	Contract Tests, End-to-End über Services
Onboarding	„Hier ist das Repo"	„Hier sind die 12 Repos und wie sie miteinander reden"

Für ein Team von 3–8 Entwicklern — das ist jedes MVP-Team, mit dem wir je gearbeitet haben — ist diese Komplexitätssteuer verheerend.

Die echten Kosten

Ein Kunde kam zu uns, nachdem er 4 Monate damit verbracht hatte, eine Microservices-Architektur für sein MVP aufzusetzen. Er hatte 6 Services, eine Message Queue, ein Service Mesh und ein API Gateway. Er hatte kein einziges nutzergerichtetes Feature geshippt. Wir haben das Ganze als Monolith in 3 Wochen neu gebaut.

Wie ein modularer Monolith tatsächlich aussieht

Ein modularer Monolith ist kein Big Ball of Mud. Es ist eine einzelne deploybare Anwendung mit klaren internen Grenzen. Djangos App-basierte Architektur macht das natürlich:

project/
├── apps/
│   ├── orders/           # Bestell-Domain
│   │   ├── models.py
│   │   ├── services.py   # Business-Logik lebt hier
│   │   ├── api/
│   │   └── tests/
│   ├── inventory/        # Inventar-Domain
│   │   ├── models.py
│   │   ├── services.py
│   │   ├── api/
│   │   └── tests/
│   ├── payments/         # Zahlungs-Domain
│   │   └── ...
│   └── notifications/    # Benachrichtigungs-Domain
│       └── ...
├── core/                 # Shared Utilities
├── config/               # Settings, URLs, WSGI
└── docker-compose.yml    # Ein Service. Das war's.

Jede App hat eigene Models, Services, API und Tests. Sie kommunizieren über klar definierte Python-Interfaces — keine HTTP-Calls, keine Message Queues, kein gRPC. Einfach Funktionsaufrufe mit Type Hints.

# apps/orders/services.py
from apps.inventory.services import check_stock, reserve_items
from apps.payments.services import charge_customer

class OrderService:
    def create_order(self, customer_id: str, items: list[OrderItem]) -> Order:
        stock_status = check_stock(items)
        if not stock_status.available:
            raise InsufficientStockError(stock_status.missing)

        reservation = reserve_items(items)
        payment = charge_customer(customer_id, calculate_total(items))

        order = Order.objects.create(
            customer_id=customer_id,
            payment_id=payment.id,
            reservation_id=reservation.id,
            status=OrderStatus.CONFIRMED,
        )
        order.items.set(items)
        return order

Das ist die Domain-Trennung von Microservices mit der Einfachheit eines Monolithen. Eine Datenbank. Ein Deployment. Ein Debugger. Volle Typsicherheit über Grenzen hinweg.

„Aber was ist mit Skalierung?"

Das ist das Argument, das wir am häufigsten hören. Die Wahrheit: Die meisten MVPs — und die meisten Produktionsanwendungen — sind nicht CPU-bound bei einzelnen Services. Sie sind I/O-bound auf der Datenbank.

Die Skalierungs-Faustregel

Wenn ihr weniger als 15 Entwickler und weniger als 100.000 täglich aktive Nutzer habt, bewältigt ein gut gebauter Monolith alles, was ihr braucht. Wenn ihr diese Zahlen erreicht — Glückwunsch, dann könnt ihr euch das Engineering-Team für Microservices leisten.

Wann Microservices Sinn machen

Wir sind meinungsstark, nicht dogmatisch. Microservices sind die richtige Wahl, wenn:

Mehrere Teams (15+ Entwickler) unabhängig deployen müssen
Unterschiedliche Technologie-Anforderungen — ein Service braucht Python ML, ein anderer Go für Performance
Regulatorische Isolation — Payment-Processing muss in einer separaten Sicherheitsgrenze sein
Echte Skalierungs-Engpässe — eine Komponente braucht 50x die Ressourcen der anderen

Wenn nichts davon zutrifft, zahlt ihr eine Komplexitätssteuer für architektonische Prahlerei.

Der Migrationspfad

Das Schöne am modularen Monolithen ist, dass einen Service später herauszulösen einfach ist. Jede App hat bereits klare Grenzen, eigene Models und eine definierte API. Wenn Order-Processing in Jahr 2 wirklich unabhängig skalieren muss:

Die orders/-App ins eigene Repo kopieren
Direkte Funktionsaufrufe durch API-Calls ersetzen
Eigene Datenbank und Migration aufsetzen
Unabhängig deployen

Das ist ein Zwei-Wochen-Projekt, kein Sechs-Monate-Rewrite.

Das Fazit

Wir bauen MVPs in 4 Wochen. Diese Timeline ist nur möglich, weil wir keine Zeit auf Infrastruktur verschwenden, die dem Produkt nicht dient.

Ein modularer Monolith gibt euch alles, was Microservices versprechen — Domain-Trennung, saubere Grenzen, testbare Komponenten — ohne die operationale Komplexität, die kleine Teams killt.

Baut den Monolithen. Shippt das Produkt. Löst Services heraus, wenn die Daten es euch sagen, nicht wenn ein Blogpost es euch sagt.

Inklusive diesem.

Wir bauen modulare Monolithen, die in 4 Wochen shippen. Erfahre mehr über unseren MVP-Entwicklungsansatz.