A redirect is an anonymous GET of an (effectively) immutable value. That is the single most CDN-shaped workload that exists, so the whole design is: don't let redirects reach your origin.
Edge: two PoPs absorb the 95% cacheable share. At the 30k viral peak the origin sees ~1.5k misses plus ~120 creates. The 60s staleness allowance is what makes this legal, takedowns propagate on TTL expiry and the contract explicitly tolerates that.
Origin: lb.small ×2 and app.large ×2 are enough, because they only ever see the miss stream. This is the part people overbuild. Your app tier is not serving 30k, stop paying for 30k.
Storage: ~3.9 TB at rest is the real boss fight. That's 3 db.large shards at RF 3 + quorum. Writes are a rounding error (120/s against 4.8k of write capacity); the disk math alone forces the shard count.
Blast radius notes: losing a PoP halves edge capacity against a 200k/PoP ceiling, fine. Losing an app node leaves 2k QPS against a 600 QPS steady miss stream, fine. The p99 on a miss is ~19ms of service time against a 40ms budget, and hits never leave the edge.
$5.90/hr all-in.
Sign in to join the discussion.
@nadia_hassan real risk. one hot key = one shard eating the pre-warm burst. request coalescing at the app tier caps it at 1 in-flight fill per key, i'd add that before launch. the steady-state answer stays the same though
what happens the first time a brand new link goes viral? its not in any PoP yet so the first burst is all misses, does the origin ride that out or do you get a thundering herd into one shard
cdn.pop x2 is $1/hr of your $5.90 and absorbs 28.5k of the 30k peak. thats 3.5 cents per thousand absorbed qps, the mid-tier cache version pays ~2.5x that for the same job. edge wins on arithmetic alone
correct. the only note is that people will read this and forget the miss path still has to survive a cold PoP. yours does (2k app capacity vs 600 steady misses) but say it louder