Design a Global Caching Service for Small Images Backed by a Single Database

Design a global caching service for small images. The service is backed by a single database, which holds every image and is the source of truth. Design the read path, the update path, the cache hierarchy, the cache invalidation or refresh mechanism, and failure handling for this system. ```hint Protect the one database Count how many cache misses can reach the database at the same moment, for example right after a popular image changes. ``` ```hint Does the key change when the image does? Compare invalidating a cached copy in place with giving every new version of an image a new identity. ``` ### Clarifying Questions - How small is "small" (typical and maximum size), how many images exist, and what fraction of them is requested frequently? - Where are the readers: which regions, and what read latency is expected? - What is the ratio of reads to updates, and how often does a given image change? - After an image is updated, how soon must every reader see the new version? Is briefly serving the old version acceptable? - Do clients fetch images by a stable ID that must always show the latest version, or can the URL change when the image changes? - Can the database be replicated for reads, or must every miss go to the single primary? ### What a Strong Answer Covers - The cache hierarchy (client, edge, regional, origin) and what each tier stores and why - A read path that shields the single database: request coalescing, a shielding tier, and negative caching - An update path and an explicit freshness guarantee - The invalidation or refresh strategy: versioned keys, TTLs, purge events, stale-while-revalidate, with their trade-offs - Failure handling for cache nodes, whole regions, the invalidation channel, and the database itself - Hot keys and cache stampedes - Capacity estimates from the agreed numbers and the monitoring that shows the cache is working (hit ratio per tier, origin load) ### Follow-up Questions - An image is removed for legal reasons and must disappear everywhere within minutes. What does your design guarantee? - One image suddenly receives a large share of all traffic. What happens at each tier? - The database is down for an hour. Which requests still succeed, and what do users see? - How would you change the design if the images were large videos instead of small images?