244 kB, 500 a minute, 5 percent: three ceilings that fail for the same reason

Each of these ceilings is enforced at an instant, while every number teams use to plan for them is an average over a window. A token bucket refills at a fixed rate up to a burst capacity, so a client can burst to capacity at once and still never sustain more than the refill ^[10]. Twenty requests a minute is the mean for a client that does 800 during a deploy ^[4]. GitHub's 5,000 an hour is 83.3 a minute, which is the figure a burst actually meets ^[16]. The planner has the same property in a different unit: selectivity is rows returned over rows total ^[13], and what the planner is handed is a bound value, not a column. A `status` column with two values averages to 0.5, while `active` is 0.95 and `pending` is 0.05 ^[5].

The retry arithmetic is where averaging gets expensive. In the guide's worked case, 800 requests a minute against a 500 limit with a 30 percent retry fraction gives 160 percent utilisation, 300 throttled per minute and 890 effective requests a minute; two minutes of that is priced at $3.56, or $76k a month sustained ^[26]. Carry the sustained figure out and it is $76,896 over a 43,200-minute month ^[20]. The bucket only admits 500 a minute, which is $43,200 of traffic in that same month, so about $33,700 of the headline is requests the provider refused ^[21]. The ceiling being modelled is on admitted throughput, not on spend, and the queue the guide prescribes (p-limit at a concurrency of 10) is the only thing that moves it, along with batching where the provider allows N calls to become 1 ^[11][12].

The database side prices out the same way. For `status = 'active'` on 100,000 rows with 95,000 active, the index scan costs 380k against a sequential scan's 100k, so the planner takes the scan; for a single-row `email` lookup it is 4 against 100k ^[14]. That is an index path 3.8 times more expensive than not using the index at all ^[23], for an index someone almost certainly added on purpose.

On the frontend the distinction is visible in the diff. lodash imported whole is 71.0 kB parsed and 24.4 kB gzipped, 122 ms of transfer on a 1.6 Mbps 3G link and 22 ms on 9 Mbps 4G ^[6]; `lodash/get` is 7.2 kB parsed, 2.9 kB gzipped, 15 ms on 3G ^[7], which is 8.4 times smaller on the line that matters ^[24]. The saving only exists if the bundler can drop the rest, and webpack tree-shakes `lodash-es` and named ESM imports, not the default `lodash` import ^[8]. A reviewer can check the import form by reading the patch; the gzip number needs a build, which is the argument for a CI budget of 130 kB per route and pasting the computed budget percentage into the PR description ^[9]. Swapping moment for date-fns is another 14 kB and 70 ms on 3G ^[18].

Two caveats on the thresholds themselves. The browser figure is where Lighthouse begins penalising Time to Interactive ^[27], a scoring penalty rather than a hard failure, which is exactly why it functions as a budget nobody notices breaking. And this is one guide, with figures reproducible through its own three calculators ^[17], so the constants are worth re-deriving against your provider tier and your planner before they become a merge gate.