Why Your Website Slows Down (or Breaks) During a Traffic Spike
A sudden rush of visitors is usually a good problem to have — unless your site's API calls weren't built to survive it. Here's what actually breaks, and how caching fixes it.
Project: Hadesopen →A traffic spike should be the good kind of problem. It's often not, because the part of a site that quietly worked fine at low traffic — a live API call on every page load — starts failing exactly when it matters most.
Where this actually shows up
Hades is a hub for a FiveM content crew, with a multi-POV theater that grid-syncs several live Twitch, Kick, and YouTube streams at once, plus a video archive fed from the YouTube API. YouTube's API has a daily quota. If every page load triggered a fresh API call, a busy day — exactly when people are checking in on a live stream — is exactly when the quota runs out and the archive stops loading for everyone.
The fix wasn't a bigger quota. It was a scheduled function that refreshes the video list once a day and caches it, so every actual page load reads from the cache instead of hitting the API at all. Traffic can spike as much as it wants; the API call volume stays flat.
The general pattern
This isn't specific to YouTube's API — it's the shape of most "site breaks under load" stories:
- Something gets fetched fresh on every request that doesn't actually need to be fresh every time (a video list, a product catalog, an exchange rate).
- That fetch has a cost or a limit — a rate limit, a quota, a slow upstream, a per-request bill — that's invisible at low traffic and very visible at high traffic.
- Nobody notices until the spike, because the whole point of a spike is that it's the one moment volume tests something that was never tested before.
Caching breaks the link between "how many visitors are on the site right now" and "how many times we hit the thing with the limit." A refresh runs on a schedule or an event, not on every page view, so ten visitors and ten thousand visitors cost the backend the same amount.
What to ask before you actually have a spike
- Does anything on the homepage or a high-traffic page make a live call to a third-party API on every load?
- Does that API have a rate limit, a quota, or a per-request cost?
- If that call failed or got rate-limited right now, would the page break, or would it degrade gracefully? (See what progressive enhancement actually buys a client for the degrade-gracefully side of this.)
If the honest answer to the first two is "yes," it's worth fixing before the spike, not during it — sales, launches, and viral moments are not when you want to be debugging a rate limit for the first time.
If you're not sure whether your site has this kind of hidden ceiling, see how I approach this or reach out — it's a quick thing to check before it's an urgent one.