The API rate limit that takes down a site nobody warned you about

A site integrates a third-party API, a payment processor, a shipping calculator, a CMS, and everything works fine through development and launch, because development and launch traffic never gets close to the API's rate limit. The limit stays invisible until real traffic crosses it, and by then it's showing up as a production outage rather than a planning conversation.

This is a specific, common blind spot because rate limits rarely show up in a vendor's onboarding documentation with the prominence they deserve, and testing environments almost never simulate the concurrent traffic that would actually trigger them. The first time a team learns their limit is 100 requests per minute is often the day traffic briefly exceeds it.

The fix is boring and preventive: before launch, explicitly find and document the rate limit for every third-party API a site depends on, model what traffic would need to look like to approach it, and build a caching or queuing layer for anything close to that threshold rather than discovering the limit during a traffic spike, which is reliably the worst possible time to discover it.

Rate limits are one of the few production failure modes that are entirely knowable in advance, sitting in a vendor's documentation the whole time. The sites that get caught by them are almost always the ones that never checked, not the ones that checked and got an unlucky surprise anyway.