Ein SaaS nach dem Launch skalieren, ohne das Produkt zu zerstören

Alle feiern den Launch. Fast niemand warnt Sie vor dem, was danach kommt — diesem merkwürdigen, nervenaufreibenden Jahr, in dem das Produkt, das Ihnen die ersten hundert Kunden gebracht hat, unter dem Gewicht der nächsten tausend zu ächzen beginnt. Nichts Dramatisches passiert. Die Dinge werden einfach langsamer, fehleranfälliger, schwerer zu ändern. An irgendeinem Dienstag merken Sie, dass eine Funktion, die früher einen Tag brauchte, jetzt eine Woche dauert, und niemand kann so recht sagen, warum. Genau dort, nicht beim Launch, werden die meisten SaaS-Produkte still gewonnen oder verloren.

Wir haben mit vielen Gründern genau an diesem Punkt gesessen. Sie scheitern nicht — das ist das Verwirrende daran. Der Umsatz steigt, das Team wächst, die Demos laufen gut. Doch darunter ächzt das Produkt. Die Support-Tickets steigen schneller als die Nutzerzahlen. Deploys, die früher langweilig waren, gehen jetzt mit angehaltenem Atem einher. Die Codebasis, die vor einem Jahr clever wirkte, fühlt sich nun wie ein Minenfeld an, in dem jede Änderung etwas anderes auszulösen droht. Sie haben nichts falsch gemacht. Sie sind nur über das hinausgewachsen, was sie gebaut haben, und niemand hat ihnen gesagt, dass genau das passieren sollte.

Dies ist also der Leitfaden, den wir uns für mehr Gründer wünschen würden, bevor die Risse auftauchen. Es geht nicht um Hyperscale, Kubernetes oder das, was irgendein Einhorn bei fünfzig Millionen Nutzern getan hat. Es geht um die langweilige, entscheidende Mitte — den Weg von es funktioniert für wenige zu es funktioniert für viele — ohne alles neu zu schreiben, Ihre Kunden zu verschrecken oder Ihr Team auszubrennen. Das Ziel ist keine perfekte Architektur. Es ist ein Produkt, das weiter wächst, statt eines, das still zu brechen beginnt.

Was tatsächlich bricht, wenn ein SaaS wächst

Hier ist der Teil, der Gründer am meisten überrascht: Skalierungsprobleme kommen fast nie als der dramatische Ausfall, auf den Sie sich gefasst machen. Der Server fängt nicht Feuer. Stattdessen entwickelt das Produkt eine Art leichtes Dauerfieber. Seiten, die sofort luden, brauchen plötzlich drei Sekunden. Ein Bericht, der für frühe Kunden problemlos lief, läuft beim großen Neukunden in einen Timeout. Derselbe Bug taucht immer wieder auf, weil zwei Teile des Codes heimlich voneinander abhängen, auf eine Weise, die niemand dokumentiert hat.

Was wirklich bricht, sind selten Ihre Server — es sind Ihre Annahmen. Anfangs haben Sie für die Gestalt Ihrer ersten Nutzer gebaut: ein paar Accounts, kleine Datenmengen, einfache Abläufe, alle ungefähr gleich. Wachstum fügt nicht einfach mehr vom Gleichen hinzu. Es fügt Vielfalt hinzu. Ein Kunde mit dem Zehnfachen an Daten. Ein Team, das eine Funktion auf eine Weise nutzt, die Sie sich nie vorgestellt haben. Eine Spitze um 9 Uhr montags, wenn sich alle gleichzeitig anmelden. Jeder davon verletzt still eine Annahme, die vor einem Jahr in Ihren Code eingebacken wurde, als ihre Verletzung undenkbar war.

Die vier Stellen, an denen es sich zuerst zeigt, sind vorhersehbar. Die Datenbank ist fast immer der Kanarienvogel — Abfragen, die auf kleinen Tabellen sofort liefen, kriechen, je größer die Daten werden. Der langsame Endpunkt: ein oder zwei Seiten, die pro Anfrage zu viel Arbeit verrichten, unproblematisch, bis sich der Traffic staut. Der fragile Deploy, bei dem das Ausliefern von irgendetwas beängstigend geworden ist, weil der Code zu verworren ist, um ihn noch zu durchschauen. Und die Support-Last, die gar keine Infrastruktur ist, aber das ehrlichste frühe Signal dafür, dass das Produkt nicht mehr zu der Art passt, wie die Menschen es tatsächlich nutzen.

Die Falle, Probleme zu lösen, die Sie noch gar nicht haben

Bevor wir übers Beheben reden, eine Warnung, die mehr Produkte gerettet hat als jede Optimierung. Die größte Bedrohung für ein wachsendes SaaS ist nicht, Skalierung zu ignorieren — es ist, sie zu früh zu jagen. In dem Moment, in dem ein Gründer die erste Verlangsamung spürt, ist der Instinkt, nach der Architektur zu greifen, über die er auf einem berühmten Engineering-Blog gelesen hat. Microservices. Eine Message Queue. Ein Multi-Region-Setup. Die Datenbank zu sharden, bevor sie eine Million Zeilen enthält.

So verbringen Sie sechs Monate und ein Vermögen mit dem Bau von Infrastruktur für einen Maßstab, den Sie nicht erreicht haben, während das eigentliche Produkt stehen bleibt. Schlimmer noch, Sie haben nun jede künftige Änderung erschwert, denn ein verteiltes System ist dramatisch komplexer zu bauen und zu debuggen als das einfache, das Sie hatten. Sie haben ein Problem, das Sie noch nicht hatten, gegen ein garantiertes eingetauscht, das Sie heute haben: Es wird nichts ausgeliefert.

Die Disziplin hier ist dieselbe, die überhaupt erst gute Produkte hervorbringt: Lösen Sie das Problem vor Ihnen, nicht das, das Sie sich geschmeichelt ausmalen. Ein langweiliger, gut verstandener Monolith, den Sie schnell ändern können, wird ein modisches verteiltes System überskalieren, das Sie sich nicht anzufassen trauen. Komplexität ist ein Preis, den Sie jeden einzelnen Tag zahlen, kein einmaliger Kauf.

Messen Sie, bevor Sie irgendetwas ändern

Fast jeder Gründer, dem wir in dieser Phase begegnen, ist überzeugt, zu wissen, wo das Problem liegt. In der Hälfte der Fälle liegt er falsch — nicht aus Nachlässigkeit, sondern weil Intuition ein miserabler Profiler ist. Der Teil des Codes, der sich langsam anfühlt, ist oft in Ordnung; der wahre Übeltäter ist irgendeine stille Abfrage, die vierzigmal auf einer Seite läuft, an die niemand gedacht hat. Sie können nicht beheben, was Sie nicht gemessen haben, und Raten ist hier der Weg, auf dem Teams wochenlang das Falsche optimieren.

Sie brauchen keinen ausgefeilten Observability-Stack, um anzufangen. Sie brauchen drei langweilige Zahlen, die Ihnen ständig vor Augen sind. Welche Endpunkte am langsamsten sind und wie langsam unter echtem Traffic. Welche Datenbankabfragen insgesamt am meisten Zeit verbrauchen — nicht die langsamste einzelne Abfrage, sondern die, deren Zeit sich über Tausende von Aufrufen summiert. Und wo Fehler tatsächlich auftreten, mit genug Kontext, um sie zu reproduzieren. Mit diesen dreien lichtet sich der Nebel meist innerhalb eines Tages.

1. 1
   Grundlegendes Monitoring einschalten

   Antwortzeiten pro Endpunkt, Fehlerraten und Slow-Query-Logging auf der Datenbank. Gehostete Tools erledigen das an einem Nachmittag. Sie können keine Zahl verbessern, die Sie nicht sehen.
2. 2
   Die echten Top drei finden

   Sortieren Sie nach insgesamt verbrauchter Zeit, nicht nach Bauchgefühl. Drei Übeltäter machen fast immer den Großteil des Schmerzes aus. Schreiben Sie sie auf — das ist Ihre tatsächliche Roadmap.
3. 3
   Eines beheben, erneut messen

   Ändern Sie eine einzige Sache, dann prüfen Sie die Zahlen erneut. Bestätigen Sie, dass es geholfen hat, bevor Sie weitermachen. Zwei Änderungen auf einmal, und Sie werden nie wissen, welche entscheidend war.
4. 4
   Aufhören, wenn es gut genug ist

   Definieren Sie 'schnell genug', bevor Sie beginnen — etwa jede Seite unter einer Sekunde bei aktueller Last. Darüber hinaus ist Optimierung ein Zeitfresser, kein Gewinn.

Dieser letzte Schritt zählt mehr, als er aussieht. Performance-Arbeit ist wahrhaft süchtig machend; es gibt immer noch eine weitere Millisekunde abzuschaben. Doch Ihre Kunden spüren den Unterschied zwischen 200 ms und 120 ms nicht, und die Stunden, die Sie damit verbringen, ihr hinterherzujagen, sind Stunden, die nicht in die Funktion fließen, die das Geschäft tatsächlich wachsen ließe. Messen, die Top drei beheben, Sieg erklären, weitermachen.

Die Datenbank ist fast immer die erste Wand

Müssten wir Geld darauf wetten, wo ein wachsendes SaaS auf seine erste echte Decke stößt, würden wir jedes Mal auf die Datenbank setzen. Sie ist der eine Teil des Systems, in dem kleine frühe Entscheidungen am härtesten kumulieren. Eine Abfrage ohne Index läuft auf tausend Zeilen im Handumdrehen und kommt auf einer Million zum Erliegen. Der Code hat sich nicht geändert. Die Daten haben es — und die Daten wachsen nur.

Die gute Nachricht ist, dass die Datenbank auch der Ort ist, an dem die günstigsten Korrekturen mit der größten Wirkung liegen. Der Klassiker ist der fehlende Index: eine einzige Zeile, die eine mehrsekündige Abfrage in eine augenblickliche verwandelt, weil die Datenbank aufhört, jede Zeile zu durchsuchen, um die wenigen zu finden, die sie braucht. Direkt dahinter steht das N+1-Abfrageproblem — eine Seite, die, statt eine Frage zu stellen, der Datenbank still dieselbe kleine Frage hunderte Male in einer Schleife stellt. Beide sind häufig, beide sind unsichtbar, bis man hinschaut, und beide sind, sobald man sie gefunden hat, meist an einem Tag behoben.

Es gibt hier eine Reihenfolge, auf die man sich stützen sollte, und es lohnt sich, sie der Reihe nach zu befolgen, statt zum Ende zu springen. Beheben Sie zuerst die Abfragen — Indizes, N+1, den langsamen Bericht. Fügen Sie dann Caching für die Daten hinzu, die ständig gelesen werden, sich aber selten ändern. Erst danach ergibt es Sinn, über Read Replicas, größere Instanzen oder das Auslagern von Daten zu reden. Die meisten SaaS-Produkte brauchen die späteren Schritte nie. Sie brauchten nur die ersten ordentlich erledigt.

Das Produkt zu skalieren heißt zu skalieren, wie Sie es ändern

Hier ist die Verschiebung, die Gründer kalt erwischt: Ab einem bestimmten Punkt geht es beim Skalieren nicht mehr darum, dass das Produkt mehr Nutzer verkraftet, sondern darum, dass Ihr Team mehr Veränderung verkraftet. Als es Sie und einen Entwickler gab, hatte jeder das ganze System im Kopf. Sie konnten alles ändern, weil Sie wussten, was es berühren würde. Bei fünf oder zehn Personen zerbricht dieses mentale Modell — und der Code, der davon ausging, dass jeder alles weiß, wird zur Belastung.

Das ist der wahre Grund, warum Deploys beängstigend werden. Es ist nicht so, dass der Code über Nacht schlechter wurde; es ist, dass niemand mehr den Wirkungsradius einer Änderung vollständig vorhersehen kann. Die Lösung ist nicht Heldentum oder ein Auslieferungsstopp. Sie ist die Investition in das unglamouröse Gerüst, das einem größeren Team erlaubt, sich zu bewegen, ohne einander auf die Füße zu treten: eine automatisierte Testsuite, die das Offensichtliche an Brüchen abfängt, Deploys, die Routine statt Zeremonie sind, und eine Möglichkeit, ein schlechtes Release in Sekunden abzuschalten, statt zu hetzen.

• Eine Testsuite, die die Handvoll Abläufe abdeckt, deren Bruch katastrophal wäre — Login, Zahlung, Kernaktion. Nicht alles; die wenigen kritischen.
• Deploys, die auf Knopfdruck laufen, kein Ritual, sodass klein und häufig auszuliefern sicher statt nervenaufreibend wird.
• Ein schneller Weg zum Rollback, sodass ein schlechtes Release ein Fünf-Minuten-Ereignis ist, kein nächtlicher Vorfall.
• Feature-Flags, sodass Sie Code zuerst an wenige Kunden ausliefern und ihn sofort abschalten können, wenn er sich danebenbenimmt.
• Genug Dokumentation, sodass der Urlaub einer Person nicht einen ganzen Produktbereich einfriert.

Nichts davon taucht in einer Demo auf. Nichts davon fügt direkt eine Funktion hinzu. Und es ist genau die Arbeit, die ein Produkt, das weiter beschleunigt, von einem trennt, das mit jeder neuen Einstellung langsamer mahlt. Die Teams, die gut skalieren, sind die, die ihre Fähigkeit, das Produkt sicher zu ändern, als eigenes Feature behandeln — denn bei Skalierung ist es genau das.

Eine kurze Geschichte vom Bruchpunkt

Um das konkret zu machen, hier ein Komposit aus Arbeit, die wir geleistet haben — Details verwischt, die Gestalt lebensecht. Ein kleines SaaS zur Verwaltung von Außendienstteams war gut gestartet und auf ein paar hundert zahlende Unternehmen gewachsen. Die Gründer waren zu gleichen Teilen begeistert und erschöpft. Dann unterschrieb ihr bisher größter Kunde: eine Firma mit mehr Nutzern und mehr historischen Daten als ihre vorigen zehn Kunden zusammen.

Innerhalb einer Woche war das Dashboard, in dem alle lebten, für diesen Kunden bis zum Stillstand verlangsamt — und, seltsamerweise, für alle anderen auch. Die Support-Tickets schossen hoch. Die Gründer nahmen an, sie bräuchten einen weit größeren Server, und machten sich auf eine schmerzhafte, teure Neu-Architektur gefasst. Genau da wurden wir hinzugezogen, und der Instinkt war verständlich, aber falsch.

Wir haben die Architektur nicht angefasst. Wir schalteten das Slow-Query-Logging ein und beobachteten einen Nachmittag lang. Der Übeltäter war fast peinlich klein: Das Haupt-Dashboard lud die Auftragsliste jedes Nutzers mit einem klassischen N+1-Muster und feuerte eine Abfrage pro Auftrag ab. Für einen kleinen Kunden bedeutete das ein paar Dutzend harmlose Abfragen. Für den neuen Giganten bedeutete es Tausende pro Seitenaufruf — was auf geteilter Infrastruktur das ganze System für alle in die Knie zwang.

Die Lehre, die die Gründer mitnahmen, war nicht technisch. Sie war, dass das erschreckende Skalierungsproblem, das sie sich vorgestellt hatten — das, das einen Neubau und eine Finanzierungsrunde brauchte — sich, einmal gemessen, als ein Zwei-Tage-Fix entpuppte, der sich hinter einem furchterregenden Symptom versteckte. Sie waren kurz davor gewesen, Monate mit dem Lösen des falschen Problems zu verbringen. Diese Lücke, zwischen der eingebildeten Krise und der gemessenen, ist die Stelle, an der das meiste Skalierungsgeld verschwendet wird.

Wann es wirklich Zeit ist, ein Stück neu zu bauen

All diese Vorsicht vor verfrühter Skalierung kann sich lesen wie niemals refaktorieren, niemals neu bauen. So ist es nicht gemeint. Manchmal hat ein Teil des Produkts wirklich das Ende seines Lebens erreicht, und es noch einmal zu flicken ist die teure Wahl. Der Trick ist, den Unterschied zwischen einer echten strukturellen Grenze und gewöhnlichen Wachstumsschmerzen zu erkennen, die ein gemessener Fix bewältigen würde.

Das ehrliche Signal ist dies: Bauen Sie eine Komponente neu, wenn die Kosten, sie zu ändern, beständig höher geworden sind als die Kosten, sie zu ersetzen. Nicht, wenn sie hässlich ist — hässlicher Code, der stabil ist und selten angefasst wird, ist in Ordnung. Sie suchen nach einem Teil des Systems, in dem jede Änderung langsam und riskant ist, in dem dieselben Bugs immer wiederkehren, in dem neue Entwickler nicht sicher arbeiten können und in dem Sie die günstigeren Lösungen bereits versucht haben und an eine Wand gestoßen sind. Wenn mehrere davon gleichzeitig zutreffen, ist ein fokussiertes Neuschreiben genau dieses einen Stücks die richtige Entscheidung.

Und wenn Sie neu bauen, bauen Sie ein Stück neu — nicht das Produkt. Das vollständige Neuschreiben von Grund auf ist der Sirenengesang der Skalierung, das, was sich sauber anfühlt und am Ende ein Jahr versenkt, während Wettbewerber ausliefern. Ersetzen Sie die eine faule Komponente, hinter einer klaren Grenze, während der Rest des Produkts weiter läuft und verdient. Chirurgisch, nicht heroisch.

Häufige Fragen