Rate limiting isn't about saying "no" — it's about keeping your system stable enough to keep saying "yes."
I started by exploring rate limiting at the algorithm level — implementing a simple rate limiter and digging into ideas like token bucket behavior, burst capacity, and 429 responses. That naturally led to a bigger question: how does this translate to real-world cloud architectures?
In production, rate limiting is almost never "one thing" — it's layered.
Controls at every level
- Edge / CDN: CloudFront can enable rate limiting (monitor → block) before traffic even reaches your origin.
- WAF: Rate-based rules count requests over 1/2/5/10-minute windows and take action once thresholds are crossed.
- API Gateway: Stage/method throttles, usage plans, plus account-level per-region quotas — all designed to protect APIs from being overwhelmed.
- Compute: Lambda can throttle invocations with a 429 when concurrency/limits are exceeded.
- Downstream services: DynamoDB and SQS also throttle when you exceed provisioned/throughput constraints.
The biggest takeaway: Rate limiting is defense in depth. Put the simplest, cheapest controls as close to the edge as possible, and still expect limits further downstream.