Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
System Design · Question Set
Caching & CDN Architecture interview questions for placements and exams.
Questions
11
Included in this set
Subject
System Design
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for System Design.
Write-through persists to the database and updates the cache in the same flow, trading latency for freshness. Write-back queues DB persistence and can batch writes for speed, but risks data loss on cache failure without durable write logs.
writeThrough(k,v){ db.put(k,v); cache.set(k,v,ttl); }For complete preparation, combine this set with full subject-wise practice for System Design. You can also explore other subjects and sets from the links below.
Namespacing with a type and version keeps different shapes separate. Including query-affecting parameters ensures distinct representations map to distinct keys. Avoid bare IDs or ad-hoc keys that collide across feature changes.
key = `${ns}:v${version}:${id}?${paramSig}`Prefer precise invalidation over global flushes. Keep a mapping from product IDs to cache keys and issue targeted purge or key bump on update. Pair this with short TTLs and stale-while-revalidate so the CDN can serve slightly stale content while refreshing in the background. For dynamic fragments, use Edge Side Includes or micro-APIs with independent TTLs. On write, publish an event that triggers cache purge in edge and application caches for that product ID.
onProductUpdate(id){ purge(`product:*:${id}:*`); emit('product.updated', id); }If a key is often requested but absent, a short-lived negative cache avoids repeated origin hits. Keep the TTL small so creation appears quickly. This is common for DNS and user lookups where non-existence is frequent.
if(db.miss) cache.set(k, NULL, ttl=10s);
A cache sits closer to the user or the app to serve frequent data with microsecond to millisecond latency. That improves user-perceived speed. It also absorbs repeat reads so the origin database and services handle less load, which lowers tail latency and cost under spikes.
GET key -> cache hit? return; else read DB, set cache, return
Cache-Aside keeps the cache as a read-through sidecar controlled by the application. It is simple and widely used because it avoids placing the cache on the write path. Consistency relies on disciplined invalidation when underlying data changes.
v = cache.get(k); if(!v){ v=db.get(k); cache.set(k,v,ttl);} return v;Real workloads often follow Zipf distributions. Policies that prefer recently or frequently used items, like LRU/LFU or TinyLFU, retain high-value keys and deliver better hit rates. FIFO and random ignore access patterns and can evict still-hot items.
policy: TinyLFU admission + LRU eviction
TTL bounds staleness regardless of activity. TTI (also called sliding expiration) keeps hot items alive by renewing their expiry on each hit. Combining them allows a hard freshness cap while keeping active keys resident.
set(key,value, ttl=10m, tti=2m)
A single-flight guard lets only one worker rebuild a value while others serve stale data or wait briefly. Proactive refresh before expiry plus jitter avoids many keys expiring at once. This keeps origin stable during spikes or cold starts.
if(lock.try(k)){ v=recompute(); cache.set(k,v,ttl+jitter); lock.release(k); }Cache-Control sets TTL and revalidation behavior. ETag or Last-Modified enables conditional requests. Vary declares which request headers are part of the cache key (e.g., Accept-Encoding, Authorization when needed). These controls prevent stale or incorrect variants from being served.
Cache-Control: public, max-age=300, stale-while-revalidate=30 ETag: "ab12" Vary: Accept-Encoding
Strong consistency means reads reflect the latest write. Achieving this via write-through and synchronous invalidation increases latency and coupling; reserve it for critical correctness paths like balances or entitlement checks. Eventual consistency allows brief staleness to gain speed and resilience. Use it for catalogs, feeds, or search where minor delays are tolerable. Bound staleness with TTLs, revalidation, or read-after-write exceptions for the actor who made the change.
readYourWrites(userId, key){ bypassCacheFor(userId,key,window=5s) }