Wenn Ihr Bot viral geht: Über Nacht skalieren

Unser Slack-Bot verarbeitete drei Monate lang täglich 200 Nachrichten, ohne ins Schwitzen zu kommen. Dann erwähnte ein Tech-Blogger ihn in einem Newsletter, und wir stiegen innerhalb von 48 Stunden von 200 auf 12.000 Nachrichten.

Alles brach zusammen. Nicht dramatisch — der Server fing nicht Feuer oder so etwas. Er verlangsamerte sich einfach… und verlangsamerte sich noch mehr. Und dann begann er, Nachrichten zu verlieren. Und schließlich wurde es ganz still, während 12.000 Menschen sich fragten, warum der KI-Bot, von dem sie gerade gehört hatten, nicht antwortete.

Hier ist, was passiert ist, was wir getan haben und wie wir in einer Woche von „Spaßprojekt“ zu „Sache, auf die die Leute tatsächlich angewiesen sind“ skalierten.

Die ersten 6 Stunden: Ablehnung und Panik

Der Newsletter traf am Dienstag um 9 Uhr in den Posteingängen ein. Um 10 Uhr hatte unsere Nachrichtenwarteschlange einen Rückstand von 400 Nachrichten. Am Mittag waren es 2.000, und die Antwortzeit betrug 45 Sekunden (normalerweise unter 3 Sekunden).

Meine erste Reaktion: „Huh, das sind viele Nachrichten.“ Meine zweite Reaktion 20 Minuten später: „Oh nein.“

Der Engpass war nicht die CPU oder der Arbeitsspeicher — es war die API des KI-Modells. Jede Nachricht erforderte einen API-Aufruf, und wir stießen hart an die Ratenlimits. Unser kostenloser API-Plan erlaubte 60 Anfragen pro Minute. Wir benötigten über 200 pro Minute.

Schnelle Lösung: API-Plan upgraden. Innerhalb von 30 Minuten hoben wir unser Limit auf 500 Anfragen pro Minute an, indem wir auf eine bezahlte Stufe umstiegen. Die Warteschlange begann sich zu leeren. Krise teilweise abgewendet.

Aber dann traf die zweite Welle ein.

Stunden 6-24: Alles andere bricht zusammen

Die Erhöhung des API-Durchsatzes offenbarte all die anderen Engpässe, die wir bei niedrigem Volumen nicht bemerkt hatten.

Datenbankverbindungen waren am Maximum. Jede Nachricht löste eine Datenbankabfrage für den Benutzerkontext aus. Bei 200 Nachrichten/Tag war das kein Problem. Bei 12.000 war unser Verbindungspool erschöpft. Die Benutzer erhielten Fehlermeldungen „Dienst nicht verfügbar“.

Lösung: Größe des Verbindungspools erhöht, Connection Pooling mit PgBouncer hinzugefügt und Lese-Replikate für die Kontextabfragen implementiert.

Speicherleck im Nachrichtenhandler. Eine Variable, die den Gesprächskontext speicherte, wuchs, ohne aufgeräumt zu werden. Bei geringem Volumen wuchs sie langsam und wurde durch gelegentliche Neustarts bereinigt. Bei hohem Volumen verbrauchte sie innerhalb von etwa 4 Stunden den gesamten verfügbaren Speicher.

Lösung: Nach jeder verarbeiteten Nachricht eine ordnungsgemäße Bereinigung hinzugefügt. Dieser Fehler bestand seit dem ersten Tag — es war nur nie wichtig, bis es das wurde.

Einfadige Verarbeitung. Nachrichten wurden nacheinander verarbeitet. Eine nach der anderen. Bei 200 Nachrichten/Tag war das in Ordnung. Bei 12.000 bedeutete es, dass jede Nachricht hinter jeder anderen wartete.

Lösung: Implementierung der gleichzeitigen Verarbeitung mit einer ordentlichen Aufgabenwarteschlange. Nachrichten werden auf mehrere Arbeitskräfte verteilt. Allein dies reduzierte die durchschnittliche Antwortzeit von 45 Sekunden auf unter 5.

Der „Oh, wir brauchen eine richtige Infrastruktur“-Moment

Nach 24 Stunden wurde mir klar, dass unsere „funktioniert auf einem VPS für 10 USD/Monat“-Architektur dem nachhaltigen Wachstum nicht gewachsen sein würde. Wir benötigten:

Ein ordentlicher Lastenausgleicher. Nicht, weil wir noch mehrere Server benötigten, sondern weil wir Gesundheitsprüfungen, automatische Neustarts und die Möglichkeit zur Bereitstellung von Updates ohne Ausfallzeiten benötigten.

Eine Nachrichtenwarteschlange. Eine Redis-gestützte Aufgabenwarteschlange, die den Empfang von der Verarbeitung entkoppelt. Wenn das KI-Modell langsam ist, warten die Nachrichten in der Warteschlange, anstatt zeitlich auszulaufen. Wenn ein Worker abstürzt, wird die Nachricht erneut versucht, anstatt verloren zu gehen.

Monitoring, das tatsächlich warnt. Wir hatten Protokollierung. Wir hatten keine Warnmeldungen. Der Unterschied ist wichtig, wenn um 2 Uhr morgens etwas kaputt geht und niemand die Protokolle überwacht.

Horizontales Skalieren. Die Fähigkeit, mehr Arbeiter hinzuzufügen, wenn die Last steigt. Unsere Architektur skaliert jetzt automatisch: Wenn die Warteschlangentiefe einen Schwellenwert überschreitet, werden automatisch neue Arbeiter hochgefahren.

Was wir in einer Woche ausgeliefert haben

Tag 1-2: Notfall-Upgrade des Ratenlimits, Fehlerbehebung beim Verbindungspool, Speicherleckbehebung.
Tag 3-4: Implementierung der Nachrichtenwarteschlange, gleichzeitige Verarbeitung.
Tag 5-6: Lastenausgleicher, Monitoring mit Warnungen, horizontales Skalieren.
Tag 7: Endlich geschlafen.

Die Gesamtkosten der Infrastruktur stiegen von 10 USD/Monat auf etwa 120 USD/Monat. Aber wir gingen von 200 Nachrichten/Tag zu einem komfortablen Handling von 50.000 über. Und die Architektur kann weiter skalieren, indem einfach weitere Arbeiter hinzugefügt werden.

Die Skalierungs-Checkliste, die ich gerne gehabt hätte

Wenn Ihr KI-Bot an Fahrt gewinnt und Sie bereit sein möchten, bevor der Anstieg kommt:

Richten Sie jetzt Monitoring mit Warnungen ein. Antwortzeit, Fehlerquote, Warteschlangentiefe, Speichernutzung. Alarmgrenzen bei 2x den Normalwerten. Sie möchten von Problemen erfahren, bevor die Benutzer es Ihnen mitteilen.

Implementieren Sie eine Nachrichtenwarteschlange. Auch bei niedrigem Volumen. Sie entkoppelt den Empfang von der Verarbeitung, ermöglicht Wiederholungen und macht horizontales Skalieren später trivial.

Profilieren Sie Ihre Ressourcenverwendung pro Nachricht. Wie viele Datenbankabfragen pro Nachricht? Wie viel Speicher? Wie viele API-Aufrufe? Multiplizieren Sie diese mit Ihrem Wachstumsziel und sehen Sie, wo die Engpässe sein werden.

Testen Sie bei 10x Ihrer aktuellen Last. Verwenden Sie ein Lasttesttool, um 10x das Nachrichtenvolumen für eine Stunde zu simulieren. Schauen Sie, was bricht. Beheben Sie es, bevor es in der Produktion bricht.

Haben Sie einen dokumentierten Plan für die Hochskalierung. „Wenn der Verkehr sich verdoppelt, tun Sie diese drei Dinge.“ Einen Plan schriftlich zu haben, bedeutet, dass Sie ihn um 2 Uhr morgens ausführen können, wenn Sie halb-schlafend sind, anstatt zu versuchen, Lösungen unter Druck zu entwerfen.

Was ich über KI im großen Maßstab gelernt habe

Das KI-Modell ist normalerweise nicht der Engpass — alles, was darum herum ist, ist es. Datenbankabfragen, Kontextverwaltung, Ausgabeformatierung, Nachrichtenrouting — all die „langweilige“ Infrastruktur, die Sie beim Bau eines Prototyps überspringen. Im großen Maßstab sind die langweiligen Dinge wichtiger als die KI-Dinge.

Außerdem: Ratenlimits sind die am meisten unterschätzte Skalierungsbeschränkung in KI-Anwendungen. Ihre brillante Architektur ist egal, wenn die Modell-API nur 60 Anfragen pro Minute erlaubt. Überprüfen Sie Ihre Grenzen, bevor Sie starten, und haben Sie einen Plan, für den Fall, dass Sie diese überschreiten.

Der virale Anstieg war stressig, aber letztendlich positiv. Er zwang uns dazu, die Infrastruktur zu bauen, die wir von Anfang an hätten aufbauen sollen. Und jetzt sind wir bereit für den nächsten Anstieg — wann immer er auch kommt.

🕒 Published: March 27, 2026