Back to roadmap
Module 5 · APIs & Application LayerDay 04525 min

Rate Limiting

Cap the firehose before it floods the basement.

← PreviousNext →
Day 045

Rate Limiting

Client
client
Rate Limiter
edge
KV bucket
datastore
API
service
Signal path
Token bucket at the edge
Client
client
flow
Rate Limiter
edge
Rate Limiter
edge
flow
KV bucket
datastore
Rate Limiter
edge
flow
API
service
Memory hook

Rate Limiting: cap the firehose before it floods the basement

Mental model

turn boundaries into contracts

Design lens

Strict global limits hurt legitimate bursts.

Recall anchors
AlgorithmsWhereComms

Why it matters

Rate limits keep abusive or buggy clients from harming everyone else. The common algorithms are token bucket (burst + steady refill), leaky bucket (constant rate), and window-based counters.

Deep dive

Token bucket: B tokens cap, R refill/sec; fits APIs that allow short bursts.

Sliding window: smooth, more accurate than fixed-window.

Communicate: 429 Too Many Requests + X-RateLimit-Remaining + Retry-After.

Demo / scenario

Public API with per-key 100 req/min limit.

  1. Token bucket: 100 cap, 100/60 ≈ 1.67/s refill.
  2. Stored in Redis, atomic Lua script.
  3. On exhaust: 429 + Retry-After.
  4. Burn down monitoring per key.

Tradeoffs

  • Strict global limits hurt legitimate bursts.
  • Per-IP limits punish NATted users.
  • Per-API-key + per-user is the cleanest, but more state.

Diagram

Client
Rate Limiter
KV bucket
API
Token bucket at the edge.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →