Averages hide the whole problem
A monthly request total tells you almost nothing about how much capacity you need. What matters is the shape of the curve underneath it: when demand arrives, how sharply it rises, and how long the peak lasts.
Most real workloads are far spikier than their owners expect. Support traffic tracks business hours and outages. Marketplace demand tracks meal times and weather. Batch jobs arrive all at once by design.
Size the band, not the peak
Provisioning for the absolute peak is how dedicated infrastructure ends up more expensive than the API it replaced. The peak is, by definition, rare, and you pay for that headroom every hour it sits idle.
The better pattern is to provision the sustained band with deliberate headroom, and to plan an explicit route for everything above it.
- Provision to the sustained band, plus headroom for normal variance.
- Queue what can tolerate delay: batch work usually can.
- Overflow what cannot: an external API is a good spillover path.
- Shed or degrade last, and decide in advance what that looks like.
Overflow is a feature, not an admission
Keeping a metered API wired up alongside dedicated capacity sometimes reads as a failure of nerve. It is the opposite. It means the economics come from the base load, where they are strongest, while the tail risk is carried by something that scales instantly and that you only pay for when you use it.
It also preserves the property that matters most for reversibility: your application is still speaking to a standard interface, so any workload can move back.