Wie ein erfolgreiches Startup nach der Einführung von MSA fast innerhalb von 6 Monaten scheiterte

Kürzlich habe ich den Beitrag "Microservices Killed Our Startup. Monoliths Would’ve Saved Us" gelesen, der in ausländischen Tech-Blogs viel Aufmerksamkeit bekommen hat, und wollte hier eine Zusammenfassung teilen, weil der Inhalt so schmerzhaft treffend und zugleich nachvollziehbar war.

Er wirkt wie ein gutes „Fehlerprotokoll“, das zeigt, wie gefährlich die bedingungslose Einführung der neuesten Technologien sein kann.

---

1. Der Auslöser: „Lasst uns auch wie Netflix arbeiten“

• Situation: Seed-Investment von $2.5M eingesammelt, monatliches Umsatzwachstum von 40 %, 50.000 Nutzer. Ein Startup, das mit einem Rails-Monolithen sehr gut lief.
• Beginn des Problems: Ein Lead-Architekt taucht auf und schlägt unter dem Ruf nach „Skalierbarkeit“ die Umstellung auf MSA vor.
• Logik: „Die aktuelle Struktur ist viel zu eng gekoppelt. Schau dir Netflix oder Uber an. Wenn wir wie sie werden wollen, müssen wir auf Microservices setzen.“
• Realität: Ein Team mit 4 Entwicklern und 1 DevOps-Mitarbeiter entscheidet sich, eine Netflix-Architektur einzuführen.

2. Sechs Monate Hölle (Timeline der MSA-Einführung)

[Monat 1: Honeymoon]

• Die Auslagerung des Benachrichtigungsdienstes gelingt. Man feiert sich mit „Siehst du! Es klappt doch?“ selbst.
• Gleichzeitig beginnen aber bereits die Vorzeichen: längere Deploy-Zeiten, mehr Repositories usw.

[Monat 2–3: Die ersten Risse]

• Der Billing-Service wird ausgelagert. Dieser hängt jedoch mit User-, Inventar- und Order-Services zusammen.
• Ergebnis: Durch Netzwerklatenz verlangsamt sich die Antwortzeit von 200 ms auf 800 ms. Fällt ein Service aus, kommt es zu Kettenausfällen, bei denen alles mit abstürzt.

[Monat 4–5: Der Albtraum verteilter Transaktionen]

• Was im Monolithen mit einer einzigen DB-Transaktion erledigt wäre, erfordert in der verteilten Umgebung sogar die Einführung des Saga-Patterns.
• Der Bestand wurde reduziert, aber die Zahlung schlägt fehl, das Rollback gerät durcheinander ... Dateninkonsistenzen lösen eine Flut an Supportanfragen aus.
• Für das Hinzufügen einer einzigen einfachen Spalte müssen 6 Services angefasst werden, sodass aus einer 2-Stunden-Aufgabe 3 Tage werden.

[Monat 6: Das Team zerbricht]

• Die Entwickler stecken ihre gesamte Zeit in Infrastrukturmanagement statt in Feature-Entwicklung.
• Infrastrukturkosten: $3,000 → $12,000 (Vervierfachung).
• Ein Kernentwickler kündigt („Ich bin hergekommen, um Produkte zu bauen, nicht um den ganzen Tag an Kubernetes herumzufummeln.“)

3. Die Entscheidung: „Wir sind nicht Netflix“

Der Architekt besteht weiterhin darauf, „Service Mesh“ einzuführen und mehr Monitoring-Tools zu nutzen, doch der Autor platzt schließlich der Kragen.

> „Wir sind nicht Netflix! Netflix hat 500 Engineers, wir aber nur 4!“

Am Ende kündigt der Architekt, und das Team entscheidet sich für die Rückkehr zum Monolithen (Rollback).

4. Zurück zum Monolithen – und die Wiederbelebung

• Über 8 Wochen hinweg wird der Code wieder zu einem Monolithen zusammengeführt.
• Ergebnis:
• Die Geschwindigkeit bei Feature-Releases erholt sich (4 pro Monat → 20 pro Monat)
• Die Antwortzeit stabilisiert sich bei 220 ms
• Die Infrastrukturkosten sinken
• Vor allem steigt die Zufriedenheit der Entwickler

5. Zentrale Lehren (das Fazit des Beitrags)

1. MSA ist kein Werkzeug zur Lösung eines ‚technischen Problems‘, sondern eines ‚organisatorischen Problems‘.

• Es ist für Situationen gedacht, in denen mehr als 50 Entwickler sich gegenseitig blockieren oder die Deploy-Zyklen extrem auseinanderlaufen.

2. Netflix/Google sind nicht dein Rollenvorbild.

• Auch sie begannen mit einem Monolithen. Sie haben erst umgestellt, als sie eine bestimmte Größenordnung erreicht hatten, nicht von Anfang an.

3. Komplexität ist eine Steuer.

• Mit jedem zusätzlichen Service steigen die Betriebskosten exponentiell.

4. Netzwerkaufrufe sind nicht kostenlos.

• Ein In-Memory-Funktionsaufruf (Nanosekunden) und ein Netzwerkaufruf (Millisekunden) liegen in völlig unterschiedlichen Dimensionen.

---

Zusammenfassung in einem Satz:
„Der Monolith ist nicht der Feind. Schlechte Architektur ist der Feind. Ein Team aus 4 Leuten sollte bitte einfach einen Monolithen verwenden.“