Deine KI-gebaute App wurde gerade gefeatured. Übersteht sie den Ansturm?
Jemand hat deine App geteilt und plötzlich kommen tausend Leute auf einmal. So hilfst du deiner KI-gebauten App, einen Traffic-Ansturm zu überstehen, ohne sie in der Nacht davor neu bauen zu müssen.
Stell dir die gute Version eines schlechten Tages vor. Du hast deine KI-gebaute App in einer Community gepostet, in der du Mitglied bist, oder jemand mit großer Reichweite hat sie ausprobiert und geteilt, oder sie ist auf der Startseite eines Forums gelandet, in dem du sie nie eingereicht hast. Plötzlich wird aus dem üblichen Rinnsal an Besucher:innen eine Flut. Tausend Leute, alle in derselben Stunde am Klicken.
Das ist der Moment, für den du das Ding gebaut hast. Es ist auch der Moment, in dem viele KI-gebaute Apps still umkippen — langsame Seiten, drehende Ladekreise, ein Anmeldeformular, das sich nicht absenden lässt. Die Leute, die endlich gekommen sind, laufen gegen eine Wand und gehen wieder, und die meisten von ihnen kommen nie zurück, um es noch einmal zu versuchen.
Die gute Nachricht: Einen Traffic-Ansturm zu überstehen, hängt meist nur an einer Handvoll langweiliger Entscheidungen, die du vor dem Ansturm treffen kannst. Du musst keine Ingenieurin sein. Du musst nur wissen, an welchen Ecken du nicht sparen darfst.
Was wirklich kaputtgeht, wenn der Traffic hochschnellt
Wenn das Hundertfache der üblichen Leute deine App gleichzeitig nutzt, gehen die Dinge nicht zufällig kaputt. Sie gehen in einer vorhersagbaren Reihenfolge kaputt, und es sind fast immer dieselben drei Stellen.
Die Datenbank wird überlastet. Jedes Mal, wenn jemand eine Seite lädt, stellt deine App ihrer Datenbank meist eine Frage: “Was sind die Daten dieses Nutzers?” Eine Person, die fragt, ist nichts. Tausend Leute, die in derselben Minute dieselbe Frage stellen, können sich schneller stapeln, als die Datenbank antworten kann, und bei allen wird die Seite zur Schnecke.
Etwas außerhalb deiner App wird langsam. Die meisten KI-gebauten Apps stützen sich auf andere Dienste — E-Mails verschicken, Zahlungen verarbeiten, ein KI-Modell aufrufen. Diese Dienste begrenzen oft, wie schnell du sie aufrufen darfst. Bei normalem Traffic bemerkst du dieses Limit nie. Bei einem Ansturm stößt deine App daran, und plötzlich stockt jede Aktion, die diesen Dienst berührt.
Die App erledigt immer wieder dieselbe teure Arbeit. Wenn deine Startseite jedes einzelne Mal, wenn jemand sie besucht, eine schwere Berechnung ausführt — eine Liste holen, sie sortieren, sie formatieren — ist das bei zehn Besucher:innen in Ordnung und bei tausend brutal. Die Arbeit war schon immer verschwenderisch. Wenig Traffic hat es nur verborgen.
Achte auf das Muster: Keins davon sind neue Bugs. Der Ansturm hat nichts kaputtgemacht. Er hat Schwächen offengelegt, die schon da waren und still unter wenig Traffic vor sich hin schlummerten.
Die billigste Lösung: Cache die Dinge, die sich nicht ändern
Caching klingt technisch, aber die Idee ist einfach: Wenn die Antwort auf eine Frage für alle gleich ist und sich selten ändert, berechne sie einmal und verwende sie wieder, statt die Arbeit für jede:n Besucher:in neu zu machen.
Deine Startseite sieht für alle 1.000 Leute, die sie aufrufen, wahrscheinlich identisch aus. Warum also die Datenbank bitten, sie 1.000 Mal neu aufzubauen? Bau sie einmal, speichere das Ergebnis für ein paar Minuten und liefere diese gespeicherte Kopie an alle aus. Du hast gerade tausend teure Datenbank-Abfragen in eine einzige verwandelt.
Sag deinem KI-Builder genau das: “Cache die Startseite und die öffentliche Produktliste für fünf Minuten, damit wir nicht bei jedem Besuch die Datenbank treffen.” Alles, was für alle gleich ist und nicht sekundengenau aktuell sein muss — eine Preisseite, ein öffentliches Verzeichnis, ein Blog-Index — ist ein Kandidat fürs Caching. Die personalisierten Dinge (das eigene Dashboard, die Kontoeinstellungen) lassen sich nicht auf dieselbe Weise cachen, aber das ist während eines Ansturms meist nur ein kleiner Teil des Traffics. Die meisten Leute schauen sich dieselben paar öffentlichen Seiten an.
Lass die Leute nicht auf Dinge warten, die auch später passieren können
Hier ist ein Fehler, der leicht zu machen und leicht zu beheben ist. Sagen wir, jemand meldet sich an, und deine App schickt ihm eine Willkommens-E-Mail. Wenn deine App ihn auf der Anmeldeseite warten lässt, bis die E-Mail vollständig versendet ist, dann macht ein langsamer E-Mail-Dienst deine Anmeldung langsam — genau in dem Moment, in dem sich die meisten Leute anmelden.
Die Lösung ist, das langsame Zeug im Hintergrund laufen zu lassen. Die Person sieht sofort “Du bist dabei!”, und die E-Mail geht ein paar Sekunden später raus, ohne dass jemand darauf wartet. Gleiches Ergebnis, aber die Besucher:innen starren nicht auf einen Ladekreis, während sich ein E-Mail-Server drei Firmen weiter Zeit lässt.
Bitte deinen Builder: “Schick die Willkommens-E-Mail im Hintergrund, damit die Anmeldung nicht darauf wartet.” Dieselbe Logik gilt für alles, was nicht fertig sein muss, bevor die Person weitermachen kann — einen Bericht generieren, mit einem anderen Tool synchronisieren, eine Benachrichtigung verschicken. Wenn die Nutzer:innen das Ergebnis nicht genau jetzt brauchen, lass sie nicht darauf warten.
Hab einen Plan für “zu viele Leute”
Manchmal ist der Ansturm größer als alles, worauf du dich vorbereitet hast, und der ehrliche Schritt ist, würdevoll abzubauen statt zu kollabieren. Eine langsame App, die noch funktioniert, schlägt eine kaputte.
Ein paar einfache Varianten davon:
- Eine freundliche Wartemeldung. Wenn etwas wirklich überlastet ist, ist “Wir bekommen gerade sehr viele Besucher:innen — gib ihm einen Moment” weit besser als ein leerer Bildschirm oder eine rohe Fehlermeldung. Leute verzeihen einer beschäftigten App. Sie verzeihen keiner kaputten.
- Schalte das schwerste Feature vorübergehend ab. Wenn ein Feature das teure ist — sagen wir, eine KI-Generierung, die pro Klick echtes Geld und Zeit kostet — kannst du es während einer Spitze ausblenden und den Rest der App schnell halten. Die meisten Besucher:innen während eines Ansturms stöbern ohnehin nur, statt dein anspruchsvollstes Feature zu nutzen.
- Wisse, woher deine Rechnung kommt. Wenn deine App bei jedem Besuch ein kostenpflichtiges KI-Modell aufruft, können tausend Besucher:innen eine Überraschungsrechnung bedeuten, nicht nur eine langsame Seite. Zu wissen, welche Aktionen Geld kosten, lässt dich vorab entscheiden, was du deckeln willst.
Eine Generalprobe in dreißig Minuten
Du brauchst keine ausgefallenen Tools, um deine Schwachstellen zu finden. Du brauchst ein paar Freund:innen und eine halbe Stunde.
Bitte fünf oder sechs Leute, deine App im selben Moment zu öffnen und ein paar Minuten lang kräftig herumzuklicken — anmelden, das Hauptfeature nutzen, die belebten Seiten laden. Das ist grob, aber es bringt das Offensichtliche schnell zum Vorschein. Wenn sich die App schon mit sechs Leuten, die darauf einhämmern, träge anfühlt, werden tausend sie plattmachen. Bleibt sie flott, hast du zumindest die niedrige Hürde genommen.
Während sie klicken, beobachte, welche Seite sich am langsamsten anfühlt. Genau diese langsame Seite ist die, wo ein echter Traffic-Ansturm am meisten wehtun wird, und sie ist das Erste, was sich zu cachen oder zu vereinfachen lohnt. Du versuchst nicht, tausend Nutzer:innen zu simulieren. Du versuchst, die eine Seite zu finden, die schon bei sechs ins Straucheln gerät.
Das eigentliche Ziel
Du kannst deine App nicht unendlich kugelsicher machen, und das musst du auch nicht. Das Ziel ist nicht, bei deinem ersten viralen Moment zehntausend Leute fehlerfrei zu bedienen. Es ist, sich nicht vor den paar hundert zu blamieren, die endlich gekommen sind — sicherzustellen, dass die Leute, die du so hart angelockt hast, eine funktionierende App bekommen statt eines sich drehenden Rads.
Cache die Seiten, die sich nicht ändern. Verlagere das langsame Zeug in den Hintergrund. Hab einen Plan für “zu viele Leute”. Mach eine Generalprobe mit fünf Freund:innen, bevor du sie brauchst. Nichts davon erfordert, dass du selbst Code schreibst — nur zu wissen, worum du deinen KI-Builder bitten musst.
Wenn dann dein Moment kommt, darfst du ihn genießen, statt hektisch zu debuggen. Hier ist also die Frage, mit der es sich diese Woche zu beschäftigen lohnt: Wenn morgen tausend Leute kämen, welche Seite würde zuerst zusammenbrechen — und weißt du es schon?