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 in System Design interview questions for placements and exams.
Questions
15
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-behind (write-back) updates the cache first and persists to the database asynchronously. Write-through updates both synchronously. Write-around skips the cache on writes but lets reads fill it later.
put(k,v): cache.set(k,v); queue.enqueue({k,v});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.
Coalesce concurrent misses so only one rebuild hits the origin. Refresh hot keys before expiry with staggered jitter to avoid thundering herds at the same second.
mutex.lock(k); if(expiringSoon) refreshWithJitter();
Namespace keys by tenant and enforce auth at the edge so private responses do not leak to shared caches. Use Vary headers to separate cached variants by auth token or role when using CDNs. Encrypt sensitive payloads at rest in the cache and avoid caching personal data unless necessary. Add strict cache-busting rules on logout or permission changes.
key = tenantId + ":user:" + userId + ":profile:v2"
LFU prefers items with high access frequency, which can outperform LRU when hot sets are stable. LRU works well when recent access predicts near-future access.
policy: allkeys-lfu
Cache-Control sets TTL and cacheability. ETag or Last-Modified enables conditional GETs to validate content cheaply. CDNs and browsers use these signals to reduce origin load.
Cache-Control: public, max-age=300 ETag: "a1b2c3"
Caching brings data closer to callers and avoids repeated expensive computations or reads. This cuts tail latency and protects the origin during traffic spikes. Consistency usually becomes weaker or bounded by policy.
Client -> CDN/Edge -> App cache -> DB
TTL bounds staleness and is simple to operate. As the system matures, add targeted invalidation when specific writes must reflect quickly. Full flushes are blunt and risky during peak traffic.
SET key value EX 300 // 5 minutes
Cache-aside keeps cache as a best-effort layer. Reads check cache, then DB on miss, and set the cache. Writes go to DB first, then invalidate or set the cache as needed.
v = cache.get(k) || db.get(k); cache.set(k,v,ttl);
Include resource, id, and version or locale to prevent cross-tenant collisions and to allow safe schema evolution. Human-readable segments aid ops and debugging.
cache:user:v2:1234:profile
Per-node in-process caches and selective replication spread read load. You can also use request coalescing and small response compression to lower network pressure.
Local LRU -> Distributed cache -> DB
Tier one is the browser or app cache with conditional GETs. Tier two is CDN or edge cache close to users to absorb most hits. Tier three is a regional in-memory store like Redis to protect the origin. Each tier has its own TTL and validation policy. Together they cut latency and confine failures. Use ETag or versioned keys so edges can revalidate cheaply and avoid serving stale data after updates.
Client cache -> CDN (max-age=300) -> Redis (TTL 120) -> Service/DB
Cache-aside is simple and cheap for read-heavy workloads with tolerant staleness. On miss, fetch from the database and set the cache with TTL; invalidate on writes. It avoids write amplification but risks cold-start misses. Write-through updates cache and DB synchronously on writes. Reads are more likely warm and consistent with the last write, but write latency is higher. Use write-through when freshness of just-written items matters and write rates are moderate.
cache-aside: get→miss→db→set; write-through: set cache + persist
Maintain a single-flight lock per key so only one worker recomputes on expiry. Serve stale-while-revalidate for a short window so users get a recent snapshot while refresh happens. Add jitter to TTL to spread expiries and pre-warm at scheduled times. Keep a fast fallback like a smaller top-N precompute to degrade gracefully if both cache and origin are slow.
if(nearExpiry && !lock.held(k)) spawnRefresh(k); return cachedOrStale(k);
Balance size, speed, and compatibility. JSON is human-friendly but larger; MessagePack or ProtoBuf are compact and fast. Include versioning to handle schema changes without mass invalidation. Avoid embedding unstable fields like timestamps in cache keys to improve hit rate; keep them in payload if needed.
value: { v:2, data: <binary> } // v is schema versionNegative caching stores the fact that a lookup returned no result to shield the database from repeated misses. Use short TTLs so real new data appears soon. It is useful for user handles, feature flags, or sparse entities where misses dominate. The risk is hiding recent inserts or fixes, so bound TTL tightly and add explicit invalidation on create.
cache.set("user:handle:foo", null, 30s) // miss remembered for 30s