#249 Resilience Engineering: Rate Limiting oder wie 429 dein System rettet

Rate Limiting klingt erstmal wie ein nerviges Nein. In Wahrheit
ist es oft der Unterschied zwischen stabiler Plattform und dem
Klassiker: kurz ein bisschen Traffic, und plötzlich ist alles
down. Denn Systeme scheitern selten an einem Request, sondern
fast immer an zu vielen: Retry Storms nach einem Funkloch,
Thundering Herd nach einem Cache-Expire, Traffic Amplification in
Microservices oder einfach ein Tenant, der als Noisy Neighbor das
ganze Haus wachklingelt.


In dieser Episode gehen wir gemeinsam tief ins Reliability- und
Resilience-Engineering und bauen Rate Limiting von Grund auf. Wir
klären, wozu Rate Limiting wirklich da ist, wie es sich von Back
Pressure, Graceful Degradation, Fault Isolation und Load Shedding
abgrenzt und wo du es in deiner Architektur verankerst: Client,
Edge, API Gateway, Sidecar Proxy wie Envoy oder direkt an
Ressourcen wie Datenbanken und Queues.


Dann wird es konkret: Wir vergleichen die gängigen Strategien und
Algorithmen, Fixed Window, Sliding Window, Token Bucket und Leaky
Bucket, inklusive Bursts, Fairness und der Frage stateful vs.
stateless. Dazu kommt die Realität: Was machst du, wenn der Rate
Limiter selbst ausfällt – Fail Open vs. Fail Closed –, und warum
das nicht nur Technik ist, sondern auch Produktmanagement,
Monetarisierung und Kundenerlebnis.


Als Bonus schauen wir auf Best Practices aus der Praxis: wie
GitHub und Cloudflare Rate Limits via HTTP-Header kommunizieren,
warum standardisierte Header gerade wieder Fahrt aufnehmen und
wieso Rate Limiting bei GraphQL-APIs so schnell zur
Kostenberechnung im Query-AST wird.


Wenn du danach dein System nicht nur schneller, sondern auch
stressresistenter machen willst, bist du hier richtig. Und ja,
ein resilientes System darf auch mal Nein sagen, damit es morgen
wieder Ja sagen kann.


Bonus: Manchmal ist der beste Load Test ein einzelner Curl-Befehl
zur falschen Zeit.





Unsere aktuellen Werbepartner findest du auf
https://engineeringkiosk.dev/partners





Das schnelle Feedback zur Episode:


(top)  (geht
so)



Anregungen, Gedanken, Themen und Wünsche

Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle
…


EngKiosk Community:
https://engineeringkiosk.dev/join-discord 

LinkedIn: https://www.linkedin.com/company/engineering-kiosk/

Email: stehtisch@engineeringkiosk.dev

Mastodon: https://podcasts.social/@engkiosk

Bluesky:
https://bsky.app/profile/engineeringkiosk.bsky.social

Instagram: https://www.instagram.com/engineeringkiosk/




Unterstütze den Engineering Kiosk

Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns
immer 


Buy us a coffee: https://engineeringkiosk.dev/kaffee




Links

Engineering Kiosk Episode #204 Resilience Engineering:
Timeouts, Jitter, Backoff & andere Systemretter:
https://engineeringkiosk.dev/podcast/episode/204-resilience-engineering-timeouts-jitter-backoff-andere-systemretter/

Engineering Kiosk Episode #223 Throw redundancy at the tail:
Request Hedging bei Google & Co.:
https://engineeringkiosk.dev/podcast/episode/223-throw-redundancy-at-the-tail-request-hedging-bei-google-co/

GitHub Rate Limits:
https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28

GitHub Rate Limit Header:
https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#checking-the-status-of-your-rate-limit

Cloudflare Rate Limit Header:
https://developers.cloudflare.com/fundamentals/api/reference/limits/#rate-limiting-headers

GitHub Rate limits and query limits for the GraphQL API:
https://docs.github.com/en/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api

IETF Datatracker - RateLimit header fields for HTTP:
https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/

Engineering Kiosk Episode #212 Multi-Tenant done right:
Isolationsmodelle, Cell-Based-Architecture, Shuffle Sharding
& Co mit Maximilian Schellhorn:
https://engineeringkiosk.dev/podcast/episode/212-multi-tenant-done-right-isolationsmodelle-cell-based-architecture-shuffle-sharding-co-mit-maximilian-schellhorn/




Sprungmarken

(00:00:00) Resilience Engineering: Rate Limiting


(00:03:57) Failure Modes: Retry Storms, Thundering Herd, Traffic
Spikes und Traffic Amplification


(00:04:28) Info/Werbung


(00:05:28) Failure Modes: Retry Storms, Thundering Herd, Traffic
Spikes und Traffic Amplification


(00:17:50) Wo platzierst du Rate Limiting: Client, Edge, API
Gateway, Sidecar und Ressourcen


(00:25:22) Welche Strategie passt: Bursts, Fairness und stateful
vs stateless Rate Limiting


(00:28:54) Algorithmen: Fixed Window, Sliding Window, Token
Bucket und Leaky Bucket


(00:38:36) Kommunikation: Rate Limits sauber kommunizieren und
HTTP Header


(00:44:23) Wenn der Rate Limiter ausfällt: Fail Open vs Fail
Closed


(00:50:28) Warum GraphQL Rate Limiting schwer ist: Query Kosten


(00:59:24) Takeaways: Rate Limiting als Sicherheitsgurt fuer
Resilience und Verfügbarkeit



Hosts

Wolfgang Gassler (https://gassler.dev) 

Andy Grunwald (https://andygrunwald.com/)




Community

Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in
unserer Engineering Kiosk Community unter
https://engineeringkiosk.dev/join-discord