A partner's retry loop breaks and starts flooding the API. To the server, those requests look legitimate. If it tries to serve all of them, everyone else may experience slow responses or an outage right when they need to work.
Rate limiting stops one consumer from exhausting shared resources. But the limit is not just infrastructure protection. It becomes part of the product contract.
What are we actually limiting?
Limits can apply per user, API key, organisation or operation. They can cap average request rate, allow short bursts or restrict concurrent expensive tasks. These controls solve different problems.
Reading a product page is usually cheaper than generating a complex report. Applying identical quotas to both may block useful work while still allowing costly traffic to overwhelm the system.
Why a clear rejection beats a shared outage
When a request exceeds its allowance, an API can return a clear rejection and indicate when the client should retry. In HTTP APIs, 429 is a common response. That is preferable to uncontrolled timeouts across the customer base.
But the rules must be predictable. Partners need to know their quotas, understand why they were throttled and have a way to slow down appropriately. Otherwise protection becomes a surprise change to commercial expectations.
A per-server counter is not a platform-wide limit
With several API instances, a counter stored inside one process does not enforce a global allowance. Distributed enforcement introduces its own costs around synchronisation, storage availability and failure handling.
Client quotas are also not the same as overall overload protection. Even if every customer stays under a personal limit, aggregate traffic can exceed capacity. The platform may still need admission control, queues or load shedding.
Where the commercial boundary belongs
I would start by identifying which workload hurts others and what different operations cost. Then product and engineering can agree on shared quotas, plan-specific allowances and sensible exceptions for legitimate spikes.
Success is not measured by the number of HTTP 429 responses. It is measured by the service quality protected for other users and how predictably limits work for those who encounter them.
Rate limiting earns its place when the company can say “not this many requests right now” to one consumer without breaking its promises to everyone else.