Topic 14.6
Rate Limiting (Production)
In one line
The production-shaped limiter: global policies, edge enforcement, quotas per tenant, and the fail-open story.
Think of it like this
The nightclub bouncer idea, but now applied fairly across an entire company's APIs, per customer, per feature — so one demanding customer can't accidentally (or on purpose) starve everyone else of service.
Key ideas
- 01
Standardize on: Redis-backed (10.9/12.2), Lua atomicity, per-key (tenant, API key, IP, endpoint), config-driven rules.
- 02
Enforcement layers: edge (gateway/CDN WAF — cheap, flat) + in-service (business-aware) — defense in depth.
- 03
Failures: Redis outage → fail-open with a local budget (each node allows its share) vs fail-closed (429 everyone) — decide per endpoint.
- 04
Response contract: 429 + Retry-After + X-RateLimit-* headers — clients self-throttle.
- 05
Quota types: burst + sustained (token bucket) and daily caps (fixed window) coexist.
- 06
Interview: 'rate limits are a product feature — they need versioned rules, dashboards, and a fail-open strategy'.
Explain without notes
Redis is down for a minute. For a checkout endpoint vs a search endpoint — fail open or closed? Why different?
Practice
Design the rate-limit config model (per api/tenant, burst+caps) and the Redis failover behavior.
Trade-offs
- ↔
Edge-only limits miss business-aware rules; in-service limits miss early cutoffs — the two go together.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can present rate limiting layered and with an honest failure story.