API Rate Limiting Strategy

created by Alice Johnson at Jan 15, 2026, 02:30 PM

Context

We're getting close to launching the public API, and we need to decide on our rate limiting strategy before we do.

Current situation:

  • No rate limiting in place
  • Internal usage only, so hasn't been an issue
  • Planning public launch in 2 weeks

Options Considered

  1. Fixed window - Simple but can have burst issues at window boundaries
  2. Sliding window - Better distribution but more complex
  3. Token bucket - Flexible, handles bursts well
  4. Leaky bucket - Smooth output rate

Recommendation

Token bucket algorithm with Redis as backing store.

Trade-offs

  • More complex to implement than fixed window
  • Redis dependency adds infrastructure cost
  • But: Much better user experience for bursty traffic

Questions for Team

  1. What limits per tier?
  2. How do we communicate limits to API consumers?
  3. Should we have endpoint-specific limits?

Activity

TU
Test UserJan 15, 2026, 03:45 PM

I think we should go with a token bucket algorithm. It's more flexible and handles bursts better than a simple counter approach.

BS
Bob SmithJan 15, 2026, 04:20 PM

Agreed on token bucket. What limits are we thinking? 100 req/min for free tier, 1000 for paid?

Alice Johnson added label Proposal

Jan 15, 2026, 05:00 PM

AJ
Alice JohnsonJan 16, 2026, 09:00 AM

Those numbers sound reasonable. We should also consider a separate limit for expensive endpoints like /search and /export.