Rate Limiting

HTTP Header erzählen dir, wie viel du noch darfst:

• X-RateLimit-Limit: 100 (Du darfst 100 pro Std).
• X-RateLimit-Remaining: 5 (Noch 5 übrig).
• X-RateLimit-Reset: 16999999 (Wann der Zähler nullt). Wenn du 429 bekommst, musst du warten (Backoff). Nginx Config:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

Praxisroutine

In der Praxis lernst du Rate Limiting, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Algorithmen (Token Bucket vs Leaky Bucket)

Wie zählt man?

• Fixed Window: "100 pro Minute". Problem: Wenn ich um 12:00:59 100 sende, und um 12:01:01 100 sende, sind das 200 in 2 Sekunden. Server crasht.
• Sliding Window: Glättet die Spitzen. Rechenintensiver (Redis).
• Token Bucket: Du hast einen Eimer mit 10 Marken. Jede Sekunde kommt 1 Marke dazu. Request kostet 1 Marke. Erlaubt kurze "Bursts" (Spitzen), aber langfristig konstant. Standard in AWS.

2. Distributed Rate Limiting

Wenn du 10 Server hast. Woher weiß Server A, dass User X bei Server B schon 99 Requests gemacht hat? Du brauchst einen zentralen Zähler (Redis). Alle Server fragen Redis: "Darf User X noch?". Atomic Increment (INCR). Achtung: Redis wird zum Single Point of Failure. Wenn Redis langsam ist, wird die ganze API langsam.

3. Client Side Throttling

Gute Clients (SDKs) haben Rate Limiting eingebaut. Sie senden gar nicht erst, wenn sie wissen, dass sie geblockt würden. Sie nutzen Exponential Backoff (Warte 1s, 2s, 4s, 8s...), wenn Fehler auftreten. Das verhindert den "Thundering Herd" Effekt, wenn der Server wieder hochkommt.

1. Garbage Collection beim Sliding Window Log

Ein "Fixed Window" (0-1 Minute, 1-2 Minuten) hat an den Klick-Rändern Schwächen. Ein perfider Angreifer feuert 100 Requests um 01:59 und weitere 100 Requests um 02:01. Die API bricht zusammen mit 200 req/sec (Spike), obwohl das Limit theoretisch "100 pro Minute" war. Als Antwort kam das Sliding Window Log. Jeder Request-Timestamp wird gnadenlos in einen sortierten Redis-Set (ZADD) geschrieben. Ein Skript rechnet: "Lösche (Garbage Collect) jetzt alle Timestamps des Users, die älter als CurrentTime minus 60 Sekunden sind (ZREMRANGEBYSCORE). Zähle den Rest." Das Problem: Wenn ein DDoS ins Haus trudelt, musst du millionenfach Logs wegschreiben (Speicher-Explosion), obwohl der IP-Block längst gesperrt ist. Ein Architektur-Albtraum für die DB.

2. CPU / Cost-Aware Throttling (GraphQL & AI)

Klassisches Rate-Limiting zählte HTTP Requests. "10 Requests pro IP". Das bricht bei komplexen APIs wie GraphQL oder AI-Modellen in sich zusammen. Ein /graphql Request greift 1 simplen String ab. Ein anderer /graphql Request nutzt eine tief geschachtelte Query, die der Postgres-DB hintenrum absurdeste 100-Tabellen-Joins abverlangt (DDoS mittels Complexity). Modernes Quota Management misst Kosten. Ein Request ist nicht mehr "= 1". Ein komplexer Join kostet "50 Tokens". Eine Token Limit Bucket wird nicht nach Quantity runtergezählt, sondern nach der CPU-Millisekunden-Rechnung des Backends aggregiert (Complexity Analysis before Execution). In GenAI APIs wird exakt nach "Generated Tokens" gerate-limited.

3. Load Balancer Offloading und BPF / XDP

Wo passiert das Rate-Limiting? Wenn der Traffic erst deine Django-App erreicht und Node.js den HTTP-Body parst, um dann herauszufinden "Limit erreicht (429)", verschwendest du massive CPU-Ressourcen für unerwünschten Schrottverkehr. L7 Application Layer Parsing ist teuer. Große Edge-Plattformen (Cloudflare / HAProxy) schieben das Throttling radikal auf Layer 3 / 4. Technologien wie eBPF / XDP (eXpress Data Path) injizieren C-Code direkt extrem früh in den Kernel-Space der Netzwerkkarte (NIC). Pingt eine böse IP über das Limit, wirft die Netzwerkkarte im Nano-Sekunden-Takt die Datenpakete hart in der Hardware sofort unbesehen in /dev/null, noch bevor die Linux-CPU den TCP-Handshake registriert.