When you expose an API, capacity stops being purely technical and becomes contractual. Business-to-business relationships tie revenue streams to *unfettered access* — a partner deal may depend on a guaranteed availability (e.g. 99.99%) or an agreed request rate. Rate limits encode the tiers: a postal-code API might allow a non-commercial user **1 call per minute**, while a shipping company under contract is permitted **10 calls per second**. Each tier is a different capacity commitment you must provision for. The consequence: API capacity planning is as much about justifying capital expenditure and honoring contracts as it is about scaling and architecture. Because these commitments shape business operations, fold them into planning *early* in development, not after a partner is already depending on the rate you can't sustain. --- *Source: [[The Art of Capacity Planning]] (John Allspaw, O'Reilly 2008) — Ch 2 — Setting Goals for Capacity*