Rate limiting, done right

We set limits that stop abuse and runaway load while staying invisible to normal use, with clear signals so legitimate clients know exactly what happened and when to retry.

Rate limiting exists to keep one noisy client from ruining the service for everyone. Done bluntly, though, it turns into a wall that legitimate traffic keeps hitting, trading one problem for another.

The craft is in the shape of the limit: generous for normal bursts, firm against genuine abuse, and always clear about what's happening so callers can respond instead of guessing.

A rate limiter has two customers with opposite needs: the platform, which must survive abuse, and the honest integrator, whose batch job just happens to be enthusiastic. Designing only for the first produces limits that feel like punishment; we design for both.

Honest clients get everything they need to behave: limit, remaining and reset in the response headers, a clear 429 with a Retry-After they can trust, and burst allowances that absorb spiky-but-legitimate traffic instead of rejecting it.

Internally, limits are layered, per token, per tenant and global, so one runaway script degrades one integration, not the neighborhood. The global layer is the circuit breaker you hope never trips, and the per-tenant layers are why it rarely does.