# Design a Global Small-Image Caching Service ### Prompt Design a globally distributed cache for small images. The authoritative image data is stored in one database, and that single-database constraint cannot be changed. The service must sustain hundreds of thousands of image reads per second worldwide. Images may be updated, and reads must remain fast; serving an old image for a short, bounded period after an update is acceptable. Cover the read path, update path, cache hierarchy, refresh or invalidation strategy, and behavior when components fail. **Candidate hint:** Separate the identity of an image from the identity of a particular version, then reason about what each cache can safely retain. ### Constraints & Assumptions - The origin database is authoritative and cannot be sharded or replaced as part of the answer. - Images are small enough to cache at several layers. - Brief staleness is allowed, but an indefinitely stale object is not. - State assumptions about read/write ratio, update rate, object size, and the permitted stale window. ### Clarifying Questions to Ask - Is an image addressed by a stable ID, a URL, or a content/version identifier? - Must an update become visible everywhere within a hard deadline? - Are access controls identical for every image, or can authorization affect cacheability? - What should clients observe if the origin is unavailable beyond the stale window? ### What a Strong Answer Covers - A concrete multi-layer request path and cache-key strategy - Protection of the single origin from misses, bursts, and synchronized refreshes - Update propagation with a bounded-staleness argument - Safe handling of retries, races between versions, eviction, and negative results - Regional and edge failure behavior, backpressure, and observability - Trade-offs between explicit invalidation, time-based expiry, and immutable versions ### Follow-up Questions 1. How would you handle a sudden viral image that is absent from every cache? 2. What happens if an invalidation message reaches regions in different orders? 3. How would you prevent a deleted image from being served forever during an origin outage? 4. Which metrics would prove that the origin is protected and the stale window is being honored?