Caching medium
You purge a file from your CDN to fix a critical bug. It takes 15 minutes to propagate. Why?
- A The CDN's edge servers are likely running a background garbage collection cycle that prioritizes larger media assets over static code files.
- B The purge command must physically propagate to hundreds of globally distributed Points of Presence (PoPs) to ensure a consistent invalidate state.
- C The purge request is automatically queued until the original Time-To-Live (TTL) for the file has naturally expired across all edge nodes.
- D Standard DNS propagation delays prevent the updated file paths from being correctly resolved by the CDN's primary routing layer.
Answer: B. The purge command must physically propagate to hundreds of globally distributed Points of Presence (PoPs) to ensure a consistent invalidate state.
Despite being 'global' networks, CDNs are distributed systems that must respect the laws of physics and network topology. A 'Purge' command must be broadcast from a central control plane to thousands of edge servers (PoPs). While this is often fast (seconds), temporary inconsistencies can occur due to network partitions or queueing delays.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In the Cache-Aside pattern, what happens when the application requests data that is missing from the cache (a 'Cache Miss')?
- Why use a centralized Distributed Cache (like a Redis Cluster) over local in-memory caches on each web server?
- Setting a short TTL (e.g., 60 seconds) on a cached object helps to:
- What is the primary architectural goal of introducing a cache into a system?
- Most caching systems rely on the principle of 'Temporal Locality', which states:
- Your cache uses an LRU (Least Recently Used) eviction policy. When the cache is full, which item is removed?