Zum Hauptinhalt springen

Antipatterns

Microservices scheitern selten an Technologie.
Sie scheitern an Kopplung, Ownership und falschen Schnitten.

Diese Anti-Patterns treten in der Praxis besonders häufig auf.

1️⃣ Verteilter Monolith

Beschreibung​

Mehrere Deployables existieren,
aber sie sind fachlich und technisch eng gekoppelt.

Deployments müssen koordiniert werden.
Änderungen ziehen mehrere Services gleichzeitig nach sich.

Prinzipdarstellung​

Kernaussage: Zyklische Abhängigkeiten = verteilte Kopplung.

Symptome​

  • Big-Bang-Releases
  • Viele synchrone Call-Chains
  • Gemeinsame Datenbank
  • Enge Versionsabhängigkeiten

Strukturelles Problem​

Verteilung ersetzt keine Entkopplung.

Gegenmaßnahme​

  • Fachliche Schnitte nach Domäne (Bounded Contexts)
  • Reduktion synchroner Abhängigkeiten
  • Event-basierte Entkopplung
  • Klare Service-Grenzen

2️⃣ Shared Database als Integrationsbus

Beschreibung​

Mehrere Services greifen auf dieselbe Datenbank zu. Integration erfolgt über Tabellen statt über Verträge.

Symptome​

  • Schema-Änderungen betreffen mehrere Teams
  • Implizite Kopplung
  • Schwer nachvollziehbare Abhängigkeiten
  • Transaktionslogik über Service-Grenzen hinweg

Strukturelles Problem​

Datenbank wird zur versteckten Integrationsschicht.

Gegenmaßnahme​

  • Jeder Service besitzt seine Daten
  • Integration nur über API oder Events
  • Explizite Verträge statt impliziter Tabellen

3️⃣ Chatty APIs / Zu feine Services

Beschreibung​

Services sind so klein geschnitten, dass ein Use Case mehrere synchrone Aufrufe benötigt.

Symptome​

  • Hohe Latenz
  • Komplexe Call-Chains
  • Fehlerpropagation
  • Performanceprobleme unter Last

Strukturelles Problem​

Schnitt entlang technischer Layer statt fachlicher Capabilities.

Gegenmaßnahme​

  • Services nach Business-Fähigkeiten schneiden
  • Aggregation am richtigen Ort
  • Reduktion synchroner Interaktionen
  • Async wo sinnvoll

4️⃣ Gateway als God Service

Beschreibung​

API Gateway oder Edge-Service enthält:

  • Orchestrierungslogik
  • Business-Regeln
  • Aggregationslogik

Symptome​

  • Gateway wird Bottleneck
  • Deployments hängen am Gateway
  • Fachlogik ist zentralisiert
  • Teams verlieren Autonomie

Strukturelles Problem​

Zentrale Schicht ersetzt verteilte Domänenverantwortung.

Gegenmaßnahme​

  • Gateway nur für Routing/Auth/Transformation
  • Business-Logik gehört in Services
  • Klare Verantwortlichkeiten

5️⃣ Fehlende Ownership

Beschreibung​

Services existieren technisch, aber organisatorisch fühlt sich niemand verantwortlich.

Symptome​

  • Keine klaren Service-Owner
  • Unklare SLOs
  • Incident-Pingpong
  • Wissen bei Einzelpersonen

Strukturelles Problem​

Microservices ohne End-to-End-Ownership sind nur technische Fragmentierung.

Gegenmaßnahme​

  • Ein Team pro Service (Build + Run)
  • Klare SLOs
  • Dokumentierte Verträge
  • Transparente Verantwortlichkeiten

6️⃣ Schein-Resilienz

Beschreibung​

Es gibt Timeouts, aber:

  • keine Backoff-Strategie
  • keine Idempotenz
  • keine DLQ
  • kein Monitoring

Symptome​

  • Kaskadierende Fehler
  • Unklare Ursachen
  • Retry-Stürme

Gegenmaßnahme​

  • Resilience-Standards pro Abhängigkeit
  • Circuit Breaker
  • Idempotente Consumer
  • Observability als Pflicht

Folgen dieser Anti-Patterns

  • Hohe Änderungskosten
  • Schlechte Fehlertoleranz
  • Langsame Delivery trotz „Microservices“
  • Operative Fragilität
  • Abhängigkeit von Schlüsselpersonen

Kernbotschaft

Microservices sind kein Diagramm.

Sie sind:

  • Autonomie
  • Datenhoheit
  • Ownership
  • Resilienz
  • klare Domänenschnitte

Wenn diese Eigenschaften fehlen, ist es kein Microservice-System – sondern ein verteilter Monolith mit zusätzlicher Komplexität.