Engineering · Published April 8, 2026
Rate Limiting: Protect the System Before Optimising Experience
Rate limits are not there to block users, but to keep most of the system available under abnormal traffic.
Many systems only think about rate limiting after being knocked over. Three triggers are common: retries from a third-party callback, a client script stuck in a loop, and a genuine traffic spike during a campaign. The first two are faults; the third is business.
Where limits belong
At the gateway for global limits, which blocks obviously abnormal traffic with simple configuration.
At the service for business limits, such as a maximum of a few submissions per account per minute, tied to business meaning.
At the database as a final safety net through pool size and query timeouts, never as the primary control.
Choosing thresholds
Read normal peaks from monitoring and leave two to three times the headroom. Guessing either blocks real users or does nothing.
When a limit trips, return a clear status code and retry interval so clients know what to do instead of timing out.
Log every limit event and watch the trend. Frequent trips mean capacity or design needs attention.
Rate limiting contains failure locally. One endpoint falling over should never take the whole system with it.
← Previous post
The Compound Interest of Reputation
Next post →
Write Product Docs for Your Future Self
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →