Design API Rate Limiting & Governor Limits

Salesforce publishes the numbers that make this concrete. A single Apex transaction may issue at most 100 SOQL queries and 150 DML statements, and retrieve 50,000 rows. It may allocate 6 MB of heap when synchronous or 12 MB when asynchronous, and burn 10 seconds of CPU. Cross any one of those and the runtime throws a LimitException and kills the transaction outright. Separately, an Enterprise org gets roughly 100,000 API calls a day plus 1,000 per user license, counted over a rolling 24-hour window. No org may hold more than 25 long-running requests, the ones over 20 seconds, at once. Those caps are not arbitrary. They are the reason 8,000 orgs can sit on one shared database without one of them taking the pod down.

The instinct is to reach for a token bucket at the gateway: count requests per key, compare to a limit, allow or reject with a 429. That move solves part of this, the per-org API quota, and it is the easy half. It does nothing for the part that defines Salesforce. A request that clears the gateway then runs tenant-authored Apex on a shared application server. That code can loop, allocate, and query against the same CPU and database every other tenant on the pod is using. A request counter at the door cannot see a transaction that has already been admitted spinning for 9 seconds of CPU and climbing.

So the design has two enforcement layers that look nothing alike. One is a soft, distributed, per-org counter on a rolling window at the edge, the API limit. The other is a hard, local, per-transaction meter that lives inside the execution engine and trips while the code runs, the governor limit. They protect against different failure modes, they use different mechanisms, and a strong answer keeps them separate on purpose.

The Salesforce angle

A request limiter guards the front door. A governor limit guards the room after you are already inside it. Counting API calls per org is the easy part of this prompt.