Warum Skalieren vibegecodete Apps kaputtmacht

Was es ist und warum es zählt

Eine App, die du mit Claude Code gebaut hast, läuft super mit dir und drei Freunden. Dann kommen hundert Leute gleichzeitig, und die Seiten brauchen ewig oder öffnen sich gar nicht.

Der Grund ist meistens nicht der kleine Server. Es ist die Art, wie die App mit der Datenbank spricht. Mit wenig Daten und wenigen Nutzern kostet jede Verschwendung Millisekunden. Mit vielen Daten und vielen Leuten gleichzeitig summiert sich das.

Ein Lasttest zeigt dir das vorher: Du simulierst viele Leute gleichzeitig, misst, wie lange jede Seite braucht, und findest heraus, was kaputtgeht. Du zuerst, vor deinen Nutzern.

Regel Nummer eins, ohne Ausnahme: Der Test läuft auf einer Kopie des Projekts oder in der Testumgebung (Staging), mit falschen Daten. Nie auf der Datenbank mit den echten Daten, nie auf der Live-Seite. Ein Lasttest ist ein kleiner Angriff: Auf der echten Seite bremst du die App für alle aus, die sie gerade nutzen, oder legst sie lahm.

1. Bereite den richtigen Ort vor

Bevor ich den Prompt schreibe, kläre ich drei Dinge.

1. Ich habe eine getrennte Kopie: eine Testumgebung oder das Projekt auf meinem Computer mit eigener Datenbank.
2. Ich habe einen Git-Commit gemacht, damit ich zurückkann.
3. Ich weiß, welche externen Dienste die App nutzt (Zahlungen, E-Mail, Benachrichtigungen, APIs anderer Anbieter). Im Test dürfen sie nicht wirklich aufgerufen werden.

Zum letzten Punkt: Ein Lasttest gegen eine Seite oder eine API, die nicht dir gehört, kann gegen deren Nutzungsbedingungen verstoßen. Teste nur deine eigene Testumgebung. Zum Start bitte ich Claude, das zu prüfen:

Prüf zuerst, mit welcher Datenbank und mit welchen externen Diensten das Projekt gerade verbunden ist. Wenn irgendetwas auf die echten Daten oder auf die Produktion zeigt, hör auf und sag es mir. Ich will den Test nur auf einer Kopie machen, mit falschen Daten und mit externen Diensten, die durch Attrappen ersetzt sind.

2. Der Test mit tausend falschen Nutzern

Dann schreibe ich in Claude Code das hier:

Mach einen Test mit tausend falschen Nutzern und sag mir, was kaputtgeht. Füll die Testdatenbank mit realistischen falschen Daten, schreib ein Skript, das tausend Leute gleichzeitig auf den wichtigsten Seiten simuliert (nimm ein kostenloses Open-Source-Tool, zum Beispiel k6, Locust oder Artillery), und miss, wie lange jede Seite braucht. Gib mir die drei langsamsten Seiten, den Grund und die Korrektur, die du vorschlägst. Fass den Code nicht an, bis ich ok sage.

Was dabei konkret passiert: Claude füllt die Testdatenbank mit vielen falschen, aber glaubwürdigen Zeilen: Nutzer, Bestellungen, Produkte. Das ist wichtiger, als es aussieht: Mit zehn Zeilen ist alles schnell, die Probleme zeigen sich erst bei realistischen Mengen.

Dann schreibt es ein Skript, das Anfragen an die wichtigsten Seiten schickt, als kämen sie von vielen Leuten gleichzeitig. k6, Locust und Artillery sind drei kostenlose Open-Source-Tools, die genau das machen: Lass Claude je nach Projekt auswählen.

Der letzte Satz ist der wichtigste: Erst will ich verstehen, dann entscheide ich. Das Testskript und die falschen Daten soll es anlegen, den Code der App nicht.

Für zusätzliche Sicherheit, während es dir die Korrekturen vorschlägt, nimm den Plan Mode: Shift+Tab, bis unten „plan mode on“ steht, oder /plan am Anfang deiner Nachricht. Dort liest Claude und schlägt vor, ändert aber keine Dateien, bis du den Plan freigibst. Für den Test selbst bleib draußen: Da muss es Skript und falsche Daten anlegen.

Gleich tausend oder in Stufen

Tausend Leute gleichzeitig sind viel, auch für den Computer, der den Test erzeugt. Besser in Stufen hochgehen und schauen, ab wann die Seiten langsamer werden. Und die Testumgebung ist meist kleiner als die echte: Es zählt vorher und nachher, nicht die absolute Zahl.

Mach den Test in Stufen: erst 50 Nutzer, dann 200, dann tausend. Sag mir für jede Stufe die durchschnittliche Zeit, die Zeit der langsamsten Anfragen und ab wann Fehler auftreten.

Eine Korrektur nach der anderen

Wenn es dir die Liste der drei langsamsten Seiten gibt, lass nicht alles auf einmal reparieren. Schreib:

Korrigier die erste, mach den Test nochmal und sag mir die Zeiten vorher und nachher.

Und so weiter mit der zweiten und der dritten. Wenn du alles auf einmal korrigierst und dann etwas besser wird, oder schlechter, weißt du nicht, woran es lag.

3. Die drei Dinge, die es fast immer behebt

Wenn eine Seite langsam ist, ist der Grund fast immer einer von diesen dreien.

Hundert Fragen statt einer

Eine Seite zeigt 100 Produkte. Der Code fragt die Datenbank erst nach der Produktliste und dann für jedes Produkt einzeln nach dem Preis. Macht 101 Fragen an die Datenbank für eine einzige Seite. Das nennt man „N+1-Problem“: eine Frage für die Liste, plus eine für jedes Element.

Allein merkst du es nicht. Bei tausend Leuten werden daraus hunderttausend Fragen, und die Datenbank verstopft. Und oft wirkt der Code sauber: Das Problem steckt dahinter.

Die Lösung ist, alles zusammen abzufragen: eine einzige Frage, die Produkte und Preise holt, oder höchstens zwei (die Liste, dann alle Preise auf einmal). Schreib:

Finde die Abfragen innerhalb von Schleifen und mach aus ihnen eine einzige.

Tabellen ohne Indizes

Denk an das Register hinten in einem Buch. Ohne musst du für ein Wort alle Seiten durchblättern. Die Datenbank macht es genauso: Ohne Index liest sie alle Bestellungen eine nach der anderen, um die eines Nutzers zu finden. Mit Index geht sie direkt hin.

Meistens hat die Haupt-ID jeder Tabelle schon einen eigenen Index. Die Spalten, mit denen du suchst, filterst und Tabellen verknüpfst, oft nicht. Schreib:

Leg Indizes auf die Spalten, mit denen du suchst, filterst und sortierst (Nutzer-ID, E-Mail, Datum).

Indizes sind allerdings nicht gratis: Sie brauchen Platz und machen das Schreiben etwas langsamer, weil die Datenbank bei jedem neuen Eintrag auch den Index aktualisiert. Also nur dort, wo sie gebraucht werden. Ich verlange immer einen Nachweis:

Sag mir bei jedem Index, den du hinzufügst, welche Seite oder Abfrage ihn nutzt, und zeig mir die Zeit vorher und nachher. Wenn ein Index nichts bringt, füg ihn nicht hinzu.

Daten, die jedes Mal neu geladen werden

Eine Preisliste oder ein Menü, das sich einmal am Tag ändert, muss nicht bei jedem Besuch aus der Datenbank geholt werden. Man hält es ein paar Minuten im Speicher: Das ist der Cache.

Pack die Daten, die sich selten ändern, in den Cache und sag mir, nach wie langer Zeit sie sich aktualisieren.

Auch der Cache hat seinen Preis: Die Daten können veraltet sein. Wenn du einen Preis änderst und der Cache zehn Minuten hält, sieht jemand zehn Minuten lang den alten. Deshalb musst du wissen, nach wie langer Zeit er sich aktualisiert. Und persönliche Daten eines Nutzers dürfen nicht in einem gemeinsamen Cache landen, sonst sieht sie womöglich jemand anderes.

Prüf, dass im Cache keine persönlichen Daten eines Nutzers liegen, die ein anderer Nutzer sehen könnte.

Vorsicht, wenn die App auf einem Serverless-Hosting läuft: Dort läuft der Code auf vielen Instanzen, die von selbst starten und stoppen. Der Speicher einer Instanz wird nicht mit den anderen geteilt und leert sich oft, ein Cache dort bringt also wenig. Du brauchst einen gemeinsamen Cache, zum Beispiel Redis. Frag Claude, welchen dein Hosting anbietet:

Läuft die App auf einem Serverless-Hosting? Wenn ja, sag mir, welchen gemeinsamen Cache mein Hosting anbietet, und nutz den statt des Server-Speichers.

Häufige Fehler

• Den Test auf der Live-Seite oder auf der Datenbank mit den echten Daten machen. Immer auf einer Kopie oder in der Testumgebung, mit falschen Daten.
• Mit einer fast leeren Datenbank testen. Füll sie mit realistischen Mengen falscher Daten.
• Alles auf einmal korrigieren. Eine Korrektur nach der anderen, mit den Zeiten vorher und nachher.
• Auf jede Spalte einen Index legen. Nur auf die, mit denen du suchst, filterst und sortierst.
• Ein Cache ohne klares Ablaufdatum. Leg fest, nach wie langer Zeit er sich aktualisiert, und halte persönliche Daten raus.

Checkliste

• Ich arbeite auf einer Kopie oder in der Testumgebung, nicht in der Produktion
• Die Testdatenbank hat falsche Daten in realistischer Menge
• Im Test sind die externen Dienste Attrappen
• Ich habe die Liste der drei langsamsten Seiten, mit Grund und Korrektur
• Ich habe eins nach dem anderen korrigiert, mit den Zeiten vorher und nachher
• Ich weiß, nach wie langer Zeit sich jeder Cache aktualisiert

Häufige Fragen