Der Server zählt bis 429 und macht dann die Klappe zu

Satirisches Symbolbild: ein Server-Schalter zeigt HTTP 429 Too Many Requests, davor warten kleine Anfragezettel in einer Schlange.

Geschrieben von

unter

Fiktion/Satire, mit ordentlichem Normenblech darunter: HTTP 429 „Too Many Requests“ ist ein echter Statuscode. Er wurde in RFC 6585 beschrieben; dort steht auch, dass eine Antwort einen Retry-After-Hinweis enthalten kann. MDN erklärt ihn als Meldung, wenn zu viele Anfragen in einer bestimmten Zeit eintreffen. Der Rest hier ist Blechpresse. Also: ein Server mit Stempelarm.

Um 09:12 Uhr stellte der Server den kleinen Blechtresen vor die Tür. Nicht dramatisch. Kein Rauch, keine Sirene, kein rotes Hollywoodlicht. Nur ein Schild: 429. Darunter, mit der Handschrift eines Geräts, das schon zu viele Monitoring-Dashboards gesehen hat: Sie waren sehr fleißig. Bitte seien Sie kurz woanders fleißig.

Die Anfragen kamen in Grüppchen. Erst höflich, dann sportlich, dann in dieser Art von sportlich, bei der jemand behauptet, es sei nur ein kurzer Test, während hinten bereits ein Lastwagen voller kurzer Tests rückwärts piept. Der Server zählte. Eins, zwei, drei, noch im Rahmen. Dann kam ein Skript mit sehr sauberen Schuhen und keinerlei Gefühl für Türen.

Rate Limiting klingt nach Fitnessstudio für Pakete, ist aber im Kern Hausordnung. Nicht jeder darf gleichzeitig in den Maschinenraum, auch wenn jeder ein wichtiges Anliegen in JSON gefaltet hat. Besonders nicht der kleine Bot, der „nur mal schnell“ alle fünf Millisekunden fragt, ob die Welt inzwischen anders ist. Die Welt ist nicht anders. Der Server aber wird müde.

Im Redaktionsflur der Blechpresse hängt seit heute eine Zeichnung: ein Türsteher mit Netzwerkstecker, der sehr freundlich „später“ sagt. Freundlich ist wichtig. 429 ist kein 500er-Wutanfall und kein 404er-Versteckspiel. 429 ist eher: Die Kantine ist voll, nehmen Sie eine Nummer, und nein, dieselbe Nummer hundertmal auszudrucken beschleunigt die Suppe nicht.

Natürlich gibt es feine Unterschiede, ach, die gibt es immer, sonst hätten die Konferenzräume ja keine Teppiche. Ein gutes Limit schützt Dienste, Datenbanken, Budgets und Nerven. Ein schlechtes Limit fühlt sich an wie ein Beamter, der die Stempelkissen rationiert, weil gestern jemand enthusiastisch war. Dann steht der harmlose Mensch vor der API und wird behandelt wie ein Staubsaugerroboter mit Absicht.

Der Retry-After-Zettel ist dabei die höfliche Schraube. Wenn er fehlt, bleibt nur dieses ungenaue Warten, bei dem Entwicklerinnen und Entwickler in Logs schauen, als könnten Logs Mitleid empfinden. Können sie nicht. Logs sind trocken. Sie sagen Dinge wie limit exceeded und meinen damit: Du hast geklopft, als die Tür gerade Luft holte.

Die Maschine unter dem Tisch, unser alter Druckerhund, bellte einmal bei „exponentielles Backoff“. Das macht er, wenn Wörter nach Mathematik riechen und trotzdem eigentlich Geduld bedeuten. Erst kurz warten, dann länger, nicht sofort wieder mit dem Kopf gegen die Wand. Eine erstaunlich menschliche Empfehlung, ausgerechnet aus dem Werkzeugkasten der Automaten.

Gegen Mittag beruhigte sich die Schlange. Die Anfragen standen nicht mehr übereinander wie nasse Akten, sondern kamen in Abständen. Der Server nahm den Tresen nicht weg, aber er lehnte sich innerlich zurück. Die Blechpresse notierte: Ein Limit ist keine Unfreundlichkeit. Es ist die kleine Metallkante zwischen Betrieb und Suppentopf.

Und falls Sie jetzt sofort noch einmal klicken wollen: warten Sie einen Takt. Nur einen. Die Maschine zählt mit.