Den Monolithen zu schnell aufgeteilt

Wir haben unseren Monolithen in 3 Monaten in 15 Microservices aufgeteilt. Danach haben wir 2 Jahre damit verbracht, die Grenzen zu korrigieren.

Wie wir aufgeteilt haben:

• Ein Service pro Datenbanktabelle
• „Das wirkt wie eine natürliche Grenze“
• Schnell ausliefern, später reparieren

Was wir falsch gemacht haben:

• Der Order-Service brauchte Customer-Daten
• Der Customer-Service brauchte die Order-Historie
• Jeder Request: 5+ Aufrufe zwischen Services
• Verteilte Joins über HTTP (ja, wirklich)

Die Symptome:

• P99-Latenz: 50ms → 800ms
• Ein Service down = alles kaputt
• Teams konnten nicht unabhängig releasen (der eigentliche Sinn der Übung)
• Dateninkonsistenz zwischen Services

Was wir hätten tun sollen:

• Zuerst DDD Event Storming
• Die tatsächlichen Bounded Contexts finden
• Nach Business Capability aufteilen, nicht nach Tabelle
• Grenzen anhand von Traffic-Mustern validieren

Lektion: Service-Grenzen sind das Schwierigste, was es richtig hinzubekommen gilt. Nehmen Sie sich Zeit — genau beim Grenzdesign zahlt sich ein externes DevOps- und Architektur-Review aus, vor der Aufteilung, nicht danach.

---

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.