Practice — Caching Strategies (5 questions)

You are designing the caching layer for an e-commerce product page. Requirements: 10 million products, rendered product JSON averages 5 KB, peak traffic is 50,000 requests/s, inventory must be at most 5 seconds stale, and a single relational primary comfortably handles ~10,000 simple reads/s.

1. Decide whether to cache the whole catalogue or only the hot subset, with the storage arithmetic.
2. Estimate database load at a 99% cache hit ratio and at a 95% hit ratio, and say whether either is safe.
3. A single product goes viral and receives 20% of all traffic. What do you do, and why can't the distributed cache alone handle it?

A public product-lookup API uses cache-aside: on a request for product:{id}, check the cache; on a miss, query the database, and if the product exists, write it into the cache. Your dashboard reports a healthy 99% cache hit ratio and normal database load.

Overnight, a buggy partner integration (or an attacker probing for valid IDs) starts sending millions of requests for random, non-existent product IDs — product:9182739123, product:1029384756, and so on. The database's CPU spikes hard even though the dashboard's hit ratio barely moves. Why does the cache do nothing to absorb this traffic, and what's the fix?