Episode
#249 Resilience Engineering: Rate Limiting oder wie 429 dein System rettet
- Podcast
- Engineering Kiosk
- Published
- Jan 6, 2026
- Duration seconds
- 3791
- Processing state
not_requested- Canonical source
- https://engineeringkiosk.dev
Actions
POST https://stenobird.com/v1/public/podcasts/engineering-kiosk-4681279/episodes/249-resilience-engineering-rate-limiting-oder-wie-429-dein-system-rettet/transcription-requests
Idempotently request low-priority transcript generation for this episode.GET https://stenobird.com/podcast/engineering-kiosk-4681279/249-resilience-engineering-rate-limiting-oder-wie-429-dein-system-rettet.md
Read the agent-friendly Markdown representation of this episode resource.
Summary
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. Bon…