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.“

[ahwjdekf]

So. Jetzt kommen gleich die MSA-Fanatiker angerannt.

[mhj5730]

Wenn der Service von vier Leuten gebaut wurde, gibt es wohl wirklich keinen Grund, ihn in MSA aufzuspalten.

[aer0700]

Dass Netzwerkaufrufe nicht kostenlos sind, stimmt wohl. Ein Funktionsaufruf und ein API-Call sind eindeutig nicht dasselbe.

[moderato]

Wenn man MSA einführen will, muss auch die Organisation auf MSA ausgerichtet sein ...

[ifmkl]

Ich denke, Punkt 4 trifft wohl am ehesten den Kern dessen, was gesagt werden soll. Und insgesamt kann ich dem Inhalt selbst durchaus zustimmen.

[bungker]

Ich bin hierhergekommen, um Produkte zu bauen, nicht um den ganzen Tag an Kubernetes herumzufummeln —> Das ist mit Abstand das dümmste Gelaber, das ich je gehört habe.

[hohemian]

Warum? Ich denke, das stimmt schon, wenn man sich in einer Situation befindet, in der man k8s nur um des k8s willen macht.

[roxie]

Ich mag die Kommentare von bungker, deshalb klicke ich sie einzeln an, aber bei diesem hier kann ich mich irgendwie nicht hineinversetzen. Hm, könntest du das vielleicht etwas näher erläutern?

[passerby]

Ein substanzloser AI-Post. Deshalb schaue ich mir Medium in letzter Zeit fast gar nicht mehr an.

[bsh998]

Hm ... irgendetwas wirkt seltsam.
Ich glaube, dieser Text wurde mit KI geschrieben.

[baeba]

Das spüre ich in letzter Zeit auch oft..
Ich vermute, dass viele Blogbeiträge nicht mit den eigenen Erfahrungen plus der Hilfe von AI
geschrieben werden.
Die Texte sind einfach zu logisch aufgebaut und zu leicht lesbar.

[bsh998]

Ich wollte vor allem sagen, dass das sehr nach AI klingt und es auch keine Referenzen gibt; daher würde ich es begrüßen, wenn solche Beiträge nicht geteilt würden.

[baeba]

Das ist ein Beitrag, der auf Hacker News gepostet wurde. Die meisten Beiträge, die ich hier veröffentliche, stammen von Hacker News.

https://news.ycombinator.com/item?id=46469845

Wie Sie gesagt haben ... ich sollte wohl einen Verweis auf Hacker News hinzufügen.

[baeba]

1) Zweifel an der Glaubwürdigkeit des Textes: riecht nach Marketing/AI-Generat

Kernaussage

• „Das ist zu sauber wie ein Lehrstück aufgebaut“ → es entsteht der Verdacht, dass der Text auf Sätze optimiert ist, die HN als ‘Moralstück’ mag
• Im Haupttext kleben überall Links zu kostenpflichtigen Materialien, daher war die Stimmung stark: „Ist das am Ende nicht einfach ein Verkaufstext?“
• Der exzessive Einsatz von Listen und ein Stil mit Emojis wurden als Signal für „AI slop“ bezeichnet, also hastig herausgepumpter AI-Content

Treffendes Zitat (Übersetzung)

„Wirkt so, als wäre das Ganze nur da, um dir die verlinkten kostenpflichtigen Materialien zu verkaufen. Und mit all den Listen fühlt es sich nach AI slop an.“
(Original: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

Kurzfazit

• Noch vor der Frage, ob der Inhalt stimmt oder nicht, war Reaktion Nr. 1: zu viel Verkaufsgeruch + zu viel AI-Geruch.

---

2) Kritik an Leadership/Architekt: Das Problem war nicht die Technik, sondern die ‘Entscheidungsstruktur’

Kernaussage

• „Ein Architekt in einem Team aus vier Leuten?“ – schon das allein fanden viele ein Warnsignal
• Vor allem ein Architekt, der nicht codet, bzw. eine abgetrennte DevOps-Rolle wurde stark als Bottleneck + CV-Optimierung gesehen
• Der Tenor war: Nicht Microservices haben die Firma fast ruiniert, sondern eine Struktur, in der niemand Verantwortung für Deployment, Betrieb und Schadensbegrenzung übernimmt

Hartes Zitat (Übersetzung)

„Architekten, deren Job darin besteht, ‘Regeln’ und ‘Patterns’ festzulegen, ohne selbst irgendetwas umzusetzen, sind fast immer eine schlechte Idee. Konzentriert euch einfach aufs Ausliefern. Wenn jemand nicht mal zehn Zeilen Code schreiben würde, aber die Entscheidungen monopolisiert, geht das schief.“
(Original: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

Kurzfazit

• Ziemlich stark war die Sichtweise: Nicht MSA war das Problem, sondern ein Rollendesign mit Entscheidungsmacht ohne Verantwortung.

---

3) Business-Perspektive: War MSA wirklich die Ursache für das Scheitern des Startups?

Kernaussage

• Einige Kommentare glaubten schon das Framing „an der Architektur gescheitert“ grundsätzlich nicht
• Das Kernargument: Wenn PMF, Nachfrage und Kundenbindung schwach sind, scheitert man unabhängig vom Stack
• Besonders an Details wie „Die Kunden springen ab, weil es zwei Tage langsamer wurde?“ wurde festgemacht, ob das Produkt ursprünglich überhaupt genug Wert hatte
• Zudem wurde auf einen inneren Widerspruch des Textes hingewiesen: erst „MSA hat das Startup umgebracht“, dann im Fazit „aber es hat überlebt?“ → Verdacht auf erzählerische Übertreibung

Treffendes Zitat (Übersetzung)

„Ziemlich sicher hat euer Startup ein Produkt umgebracht, das die Leute nicht wollten. Das ist ungefähr so unsinnig wie zu behaupten, Python statt Go habe euer Startup getötet.“
(Original: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

Kurzfazit

• Die Perspektive war klar vorhanden: Architektur könnte nur ein Vorwand sein, und die eigentliche Ursache lag bei Markt, Produkt und Cashflow.

---

4) Technische Einsichten: Erfahrungsbasierte Ratschläge zu Monolith vs. MSA (der tatsächlich hilfreiche Teil)

Kernaussage

• „MSA hat eine Fixkosten-Steuer in Form von Betriebs- und Komplexitätsaufwand“ → für kleine Teams kann das fatal sein, so die Erfahrung vieler
• Wichtige Stichworte: Premature distribution (zu frühe Verteilung), modularer Monolith/Modulith, und „Grenzen (boundaries) muss man sich verdienen“
• Es wurden auch realistische Bedingungen genannt, unter denen MSA sinnvoll wird: wenn das Team wächst und Konflikte, Deployments oder organisatorische Probleme tatsächlich auftreten
• Umgekehrt lautete ein weiterer Rat: Performance- und Skalierungsprobleme nicht reflexhaft mit „MSA“ lösen wollen, sondern zuerst auf Algorithmen, Bottlenecks, Sharding und Partitionierung schauen

Hartes Zitat (Übersetzung)

„Nicht Microservices haben das Startup umgebracht, sondern ‘zu frühe Verteilung’. Ihr habt aufgeteilt, bevor echte Grenzen entstanden waren, und damit nur Latenz- und Abstimmungskosten erzeugt. Fangt mit einem modularen Monolithen an, verdient euch eure Grenzen und extrahiert dann.“
(Original: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

Kurzfazit

• Das war die Lehre, mit der sich die Community tatsächlich identifizieren konnte:
  „Startet mit einem Monolithen und trennt Services erst dann, wenn Grenzen ‘natürlich’ entstehen.“

---

Gesamturteil der Community in einem Satz

Den meisten war klar: „Wir sind nicht Netflix“ – gleichzeitig war aber auch der Verdacht stark, dass dieser Text selbst eine Erzählung ist, die genau diese Netflix-Krankheit verkauft (= Marketing/AI).