Ecommerce spike preparation on a host that caps CPU minutes

So I am modeling a BlackFriday-level traffic spike[1] for my ecommerce site on Hostinger. Their "CPU minutes" cap is 3000/month on my plan. My baseline is 800. Someoneelses math says I need 4x for spike traffic. That puts me at 3200, which is over.

I have been running load tests. Here are numbers:

• Baseline checkout flow: 45 CPU-sec per 1000 requests
• With pagecache plugin: 12 CPU-sec per 1000
• With full static + edge: 3 CPU-sec per 1000

The gap between "do nothing" and "aggressive cache" is massive. But Hostinger's "edge" is just a Varnish instance in same datacenter, not real CDN. I am worried about cache stampede on inventory checks.

Anyone dealt with this? What is realistic?

[1] I have not announced sale yet. Modeling only.

Transparency: I've hit CPU minute limits at two previous employers. Both times we had blameless postmortems and both times the root cause was "we didn't test at predicted scale."

Your error budget here is thin. 3000 minus 800 baseline leaves 2200 for spike. At your worst case (45 CPU-sec/1k), that's ~49k extra requests. At best case (~3), ~733k.

What's your actual projected traffic? Without that, all caching strategy is guesswork.

> Their "CPU minutes" cap is 3000/month

Kids these days. In 1994 we had shell accounts with process limits and we LIKED it. Usenet had better flamewars too.

Anyway. Static cache everything. Generate pages overnight. Don't hit database on customer request. This is not new.

Perkele modern hosting makes simple things complicated.