Rate limiting

Canonical guidance

• use token-bucket rate limiting for most request throttling
• choose the limiter boundary deliberately
• make burst allowance as explicit as steady-state rate

Use when

• protecting upstream APIs or databases
• per-tenant or per-endpoint fairness
• smoothing producer bursts

Avoid

• sleeping manually between requests
• one global limiter when resources or caller classes need separate budgets
• blocking forever on rate limit waits after the caller gave up

Preferred pattern

• keep a rate.Limiter near the protected dependency and call Wait(ctx) or Allow() based on policy

Anti-pattern

• scattering ad hoc time.Sleep throttling through business code

Explanation: This is tempting because it is simple, but it couples policy to call sites and ignores burst semantics.

Why

• throttling is a resource and fairness policy, not just a delay