Rate Limit an API During a Traffic Attack
RenderSoftware Engineer · Technical ScreenLast updated
Design API rate limiting with token buckets, layered identities, endpoint costs, distributed-state tradeoffs, and measurable protection of legitimate traffic.
After identifying high-volume client addresses in API logs, design rate limiting to protect the API during a denial-of-service incident. Explain the enforcement point, identity, algorithm, and failure behavior.
Constraints & Assumptions
The source asks how to rate limit after a log-analysis task. Request volume alone does not establish abuse, and an IP can represent many legitimate clients. No fixed traffic scale or limit is specified.
Clarifying Questions
Which endpoints and resources are saturated? Can clients authenticate? Are bursts legitimate? What limits can be enforced at the edge versus inside the service? What should happen if the shared limiter is unavailable?
Follow-up questions
- How do you handle clients behind NAT, distributed attacks, expensive endpoints, and an attacker rotating IPs? When would an approximate local limit be preferable to a globally exact counter?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.