Warum du keine Microservice-Architektur brauchst – und warum sie dein SaaS zerstören kann

Viele Gründer glauben, Microservices seien „professionell“ und notwendig, um später zu skalieren. Die Realität in frühen SaaS-Phasen: Microservices erhöhen deinen Aufwand, bevor du überhaupt echten Nutzer-Traffic hast. Ergebnis: langsameres Shipping, höhere Kosten, mehr Koordinationsaufwand.

Die bessere Strategie: ein modularer Monolith, der sauber strukturiert ist und einen klaren Migrationspfad enthält – für den Tag, an dem du ihn wirklich brauchst.

1) Was Microservices dir tatsächlich bringen – und was sie kosten

Vorteile (später, bei echter Größe):

• Unabhängige Deployments pro Team/Service

• Technologie-Freiheit je Service

• Skalierung einzelner Hotspots (z. B. Search, Billing)

• Fehlereinkapselung

Kosten (sofort, ab Tag 1):

• Netzwerk- und Protokoll-Komplexität (HTTP/gRPC, Retries, Timeouts, Backoff)

• Datenkonsistenz (verteilte Transaktionen, Eventual Consistency)

• Observability-Aufwand (Tracing, Korrelation von Logs, Metriken)

• CI/CD-Vervielfachung (x Services = x Pipelines, x Repos)

• Infrastruktur (Service Discovery, API-Gateway, Secrets, Kubernetes)

• Orchestrierung von Releases (Versionierung von Schnittstellen, Backwards-Compatibility)

Wenn du noch kein Team mit klaren Service-Boundaries und keinen stabilen Markt-Fit hast, sind das Overhead-Kosten ohne Gegenwert.

2) Der Monolith ist nicht „altmodisch“ – er ist der kürzeste Weg zu Umsatz

Ein modularer Monolith heißt: ein Prozess, ein Deployable, aber klare fachliche Module.
Beispielstruktur (Django):

• core (Domain-Modelle, Regeln)

• accounts (Auth, User, Rollen)

• billing (Abos, Stripe, Rechnungen)

• automation (Jobs, Celery-Tasks)

• api (REST/GraphQL Endpoints)

Vorteile sofort:

• Einfache lokale Entwicklung (ein Repo, ein Server, ein Debugger)

• Eine Migration, ein DB-Schema, wenig „Klebstoff“

• Atomare DB-Transaktionen statt Eventual Consistency

• Releases in Minuten, nicht Tage

• Fokus auf Produkt, nicht auf Infrastruktur

Ergebnis: Du shipst zwei- bis dreimal schneller und validierst den Markt – bevor du überhaupt anfangen müsstest, Microservice-Probleme zu lösen.

3) Zwei echte Beispiele

Beispiel A: B2B-SaaS mit Reporting

• Annahme: „Wir brauchen Microservices, weil Reporting getrennt skaliert.“

• Realität: 200 Daily Active Users, Lastspitzen selten.

• Kosten: 6 Services, 6 Pipelines, 2 Monate DevOps-Aufbau, keine zahlenden Kunden.

• Retrospektive: Ein Monolith + asynchrone Reports (Celery + Redis) hätte gereicht.

Beispiel B: Event-Intensive App

• Start mit Monolith: Django + Postgres + Redis + Celery.

• Hotspot nach 8 Monaten: Webhook-Ingestion explodiert.

• Lösung: Nur das Ingestion-Modul als eigene Service-Unit auskoppeln (separate Queue, eigener Worker-Pool).

• Ergebnis: 90 % des Codes bleibt Monolith, ein Service wird separat skaliert. Umsatz unbeeinträchtigt, geringe Komplexität.

4) Entscheidungsregeln: Monolith vs. Microservices

Wähle Monolith, wenn mindestens eine der folgenden Aussagen stimmt:

• < 50k monatliche Events oder < 10 qps im Peak

• Ein Team < 6 Entwickler

• Anforderungen ändern sich noch stark (Produkt/Markt-Fit unsicher)

• Du hast keinen dedizierten DevOps-Engineer

Wähle punktuelle Services, wenn:

• Ein Modul klar isolierbar ist (z. B. PDF-Rendering, Ingestion, ML-Inference)

• Das Modul andere Skalierungsprofile hat (CPU-heavy, Memory-heavy)

• Kundenseitig harte SLOs existieren (z. B. Response < 200 ms für Search)

Erst echte Microservice-Landschaften, wenn:

• Mehrere Teams parallel releasen müssen

• Stabile, entkoppelte Domänen vorliegen (Bounded Contexts)

• Du Observability (Tracing, Metrics, Logging) und Versionierung im Griff hast

5) Architekturpfad: So startest du sauber – und bleibst migrationsfähig

Phase 1: Modularer Monolith

• Projektstruktur nach Domänen (keine „utils“-Sammelcontainer)

• Klare Modul-Schnittstellen (Service-Klassen statt „quer importieren“)

• Domain-Events im Code (z. B. Python-Events/Signals), noch kein Broker nötig

• Background-Jobs via Celery (Retries, Backoff, Idempotency)

Phase 2: „Service-ähnliche“ Grenzen ziehen

• Interne API-Layer zwischen Modulen (Contracts definieren)

• Datenzugriffe kapseln (Repository/Service Pattern)

• Event-Publisher zentralisieren (später austauschbar gegen Kafka/RabbitMQ)

Phase 3: Selektives Herauslösen

• Ein Modul mit klarer Lastspitze wird ausgelagert

• Schnittstelle bleibt identisch (HTTP/gRPC), der Monolith ruft nun extern

• Gemeinsames Auth/Trace-Konzept (Request-ID, Correlation-ID)

Phase 4: Plattform-Hygiene

• Feature-Flags, Circuit Breaker, Rate-Limits, Backpressure

• Observability: zentralisierte Logs, Traces, Dashboards, Alerts

• Blue/Green- oder Canary-Releases dort, wo Risiko hoch ist

So bleibt dein Code sauber, und du kannst später gezielt Services abtrennen – ohne komplette Neuentwicklung.

6) Typische Anti-Pattern, die dein SaaS ausbremsen

• „Wir starten direkt mit Kubernetes.“ → Wochen an Yaml statt Features.

• „Jedes Team kriegt seinen Service.“ → Bei 3 Entwicklern völlig unnötig.

• „Event-Driven everything.“ → Ohne Observability und Contract-Tests brandgefährlich.

• „Wir brauchen Technologie-Freiheit.“ → Heute Luxus, morgen Wartungshölle.

7) Checkliste: Bist du bereit für Microservices?

Beantworte ehrlich mit Ja/Nein:

• Du hast klar definierte Bounded Contexts.

• Du kannst Metriken, Logs, Traces korrelieren.

• Du kannst API-Versionierung und Backwards-Compatibility garantieren.

• Ein Modul verursacht signifikant andere Last oder muss separat skalieren.

• Teams blockieren sich aktuell beim Deployen.

Wenn du zwei- bis dreimal Nein sagst: Bleib beim modularen Monolithen.

Fazit

Microservices sind kein Qualitätsmerkmal.
Sie sind ein Kostenmodell – das sich erst lohnt, wenn du die Größe und die Teams dafür hast.

Starte mit einem strukturierten Monolithen, gewinne Kunden, lerne vom Markt.
Kapsle Module so, dass eine spätere Auslagerung möglich ist.
Skaliere gezielt dort, wo echte Last entsteht.

So baust du schneller Umsatz auf – und vermeidest die teuerste Falle: den Re-Write.

Wie wir helfen

Wir bei bayram.{solutions} bauen monolithisch, modular und migrationsfähig:

• klare Domänenstruktur statt Spaghetti-Code

• Async-Verarbeitung für Performance-Hotspots

• Observability von Anfang an

• Migrationspfad zu Services, falls nötig