6
Security
Rate limiting vs throttling for a public partner API
Access protection ↔ Traffic shaping
Context
Protect a public API from scrapers while keeping bursty partners happy.
Our public API serves ~40 partners. Some run batch jobs at midnight that burst to 50× normal; meanwhile scrapers and credential-stuffing bots hit login and search.
Option A: rate limiting: a token bucket per API key; beyond the limit, return 429 with Retry-After.
Option B: throttling: accept the request but queue or delay it so the backend sees a smooth rate.
Which belongs where?
Constraints
- Clients
- ~40 partners, some batch jobs at midnight
- Abuse
- Credential-stuffing and scrapers
- Infra
- Gateway + Redis
Rate limiting (reject with 429)vsThrottling (queue or slow requests down)
Community verdict
Rate limiting (reject with 429) 67%Throttling (queue or slow requests down) 33%
9 engineers · 5 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Rate limiting (reject with 429)
Throttling (queue or slow requests down)
Partner experience →
Trade-offs
Dimensions
Rate limiting (reject with 429)Throttling (queue or slow requests down)out of 5
- Abuse protection
- 5Rate limiting (reject with 429) scores 5 of 53Throttling (queue or slow requests down) scores 3 of 5
- Partner experience
- 3Rate limiting (reject with 429) scores 3 of 54Throttling (queue or slow requests down) scores 4 of 5
- Predictable server load
Community discussion
5 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentRate limiting at the edge is non-negotiable for abuse: queuing a bot's requests just means doing the bot's work slowly. 429 + Retry-After is the contract well-behaved clients understand.
For partners, give each key a token bucket with burst capacity, so midnight batches drain at a sustained rate without being rejected outright.
Token buckets cover both: the burst size shapes partners, the refill rate protects us.
Keep the counters in Redis with atomic Lua scripts, or the limit leaks across gateway replicas.
Our partners hated 429s mid-batch because their clients did not retry properly. A server-side queue for their bulk endpoints cut support tickets to zero. Better still, offer an async bulk API.
An async bulk API is the real fix. Job id now, results later, no rate fight.