Rate Limiting: Schutz, Fairness, Developer Experience.
Rate Limiting: Schutz, Fairness und Developer Experience
Rate Limiting ist kein Misstrauens-Instrument. Es ist Infrastruktur-Schutz.
Warum Rate Limiting unverzichtbar ist
Eine API ohne Rate Limiting kann durch einen einzelnen schlecht implementierten Client in die Knie gezwungen werden. Durch einen Angriff oder einfach durch einen Bug in einem Consumer, der unbegrenzt retried.
Rate Limiting schützt die Infrastruktur und garantiert faire Ressourcenverteilung unter allen Clients.
Verschiedene Rate-Limit-Strategien
Fixed Window: X Requests pro Zeitfenster (z.B. 1000 pro Stunde). Einfach zu implementieren, hat aber Burst-Problem an Fenster-Grenzen.
Sliding Window: Gleitendes Fenster über die letzten N Sekunden/Minuten. Fairer, aber etwas aufwändiger.
Token Bucket: Tokens werden über Zeit aufgefüllt, jeder Request kostet einen Token. Erlaubt kontrolliertes Bursting.
Leaky Bucket: Requests fließen mit konstanter Rate durch. Sehr gleichmäßig, kein Bursting.
Für die meisten APIs: Sliding Window oder Token Bucket sind gute Wahl.
Granularität
Rate Limits pro API-Key, pro User, oder pro IP? Abhängig vom Use Case. Für authentifizierte APIs: pro User/API-Key. Für öffentliche Endpunkte: per IP, aber mit Vorsicht (Shared NAT).
Developer Experience beim Rate Limiting
Rate-Limit-Headers in der Response: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Damit kann der Client sein Verhalten anpassen, bevor das Limit erreicht ist.
Bei überschrittenem Limit: 429 Too Many Requests + Retry-After Header.
Checkliste Rate Limiting
Rate-Limit-Strategie für jeden Endpoint definiert
Granularität der Limits festgelegt (per User/IP/Key)
Rate-Limit-Headers in Responses gesetzt
429-Response mit Retry-After
Rate Limits dokumentiert (API-Docs)
Alerts bei ungewöhnlich hohem Request-Volumen
Rate Limiting für eure API einrichten?
markom.digital implementiert Rate-Limiting-Mechanismen – angepasst an eure API-Nutzungsmuster.
