Senior Distributed Caching & CDN Interview Questions (50 MCQs)

Question 1

How does 'probabilistic early expiration' (the XFetch algorithm) reduce stampedes without locks?

Accepted Answer

Each reader refreshes early with a probability that grows as expiry nears and with recompute cost

Answer

Each reader randomly shortens or extends the key's TTL so expirations spread out

Answer

Only the reader with the smallest ID hash is allowed to recompute

Answer

Each reader bypasses the cache with a fixed 1% probability per request

Question 2

In Facebook's memcache paper, 'leases' solve two problems at once. Which two?

Accepted Answer

Stale sets (writing an old value after a delete) and thundering herds on one key

Answer

Hot keys on one shard and uneven distribution on the hash ring

Answer

Data loss during failover and split brain between replicas

Answer

Big keys and object serialization cost

Question 3

A service deletes the cache key after writing to the primary, but on a miss reads from a read replica with a few hundred ms of lag. What happens and what is a good fix?

Accepted Answer

The next miss reads the old value from the replica and re-caches it until TTL; invalidate after the replica applies it (e.g. CDC from replica) or read misses from primary

Answer

No problem, because deleting the key guarantees the next read sees the new value

Answer

The replica automatically forwards the request to the primary because the key is not cached

Answer

The cache reads the new value from the primary's binlog and ignores the replica

Question 4

What is the main limitation of the 'delayed double delete' pattern (delete, write, sleep, delete again)?

Accepted Answer

The delay is a guess; if a slow read or replica lag exceeds it, a stale set can still occur

Answer

The second delete always causes the original DB write to be lost

Answer

The pattern only works for in-process caches, not Redis

Answer

The second delete resets the TTL of every other key

Question 5

To prevent an older value overwriting a newer one in the cache, which approach is most robust?

Accepted Answer

Store a version (row version or LSN) with the value and set atomically only if the version is greater, via a Lua script

Answer

Using `SET` with `NX` so the key is written only if absent

Answer

Lowering every key's TTL to one second so staleness is brief

Answer

Adding a random `sleep` before every set so races become rare

Question 6

Why is invalidating the cache inside a DB transaction (before commit) dangerous?

Accepted Answer

Readers between delete and commit read the old value and re-cache it, and a rollback cannot undo the invalidation anyway

Answer

Because the DB forbids any network contact with the cache during a transaction

Answer

Because a cache delete locks the DB row and causes deadlocks

Answer

Because pre-commit invalidation always causes the DB transaction to abort

Question 7

In a ticketing system with bursty demand, seat availability is cached. Which design is correct?

Accepted Answer

Use the cache only as a display hint, and perform the final reservation via a conditional write or transaction on the source of truth

Answer

Reserve by decrementing availability in the cache and sync the DB hourly

Answer

Set the availability TTL to zero so the cache is always exact

Answer

Use write-behind so reservations reach the DB faster

Question 8

Why did Facebook use a small 'gutter pool' when a memcache node failed, rather than rehashing its keys onto the remaining nodes?

Accepted Answer

Rehashing can push a hot key onto a healthy node and cascade failures; a short-TTL gutter isolates that load

Answer

Because rehashing is mathematically impossible with consistent hashing

Answer

Because the gutter pool stores data on disk and never loses it

Answer

Because the gutter pool is strongly consistent while normal nodes are not

Question 9

After a cache cluster restart, the DB falls over from misses, and even after recovering, timeouts and retries prevent the cache from refilling. What is this called and how do you exit it?

Accepted Answer

A metastable failure; exit with load shedding, capping DB concurrency, and gradually warming the cache before restoring full traffic

Answer

Split brain; exit by re-electing a cache cluster leader and restarting the DB again

Answer

Cache pollution; exit by switching eviction to LFU and adding memory

Answer

A hot key; exit by copying hot keys onto several shards

Question 10

Your DB can handle only 10% of read traffic without the cache. When the whole distributed cache goes down, what should the service do?

Accepted Answer

Use a circuit breaker and rate limit to send only part of the traffic to the DB and degrade the rest (defaults, stale data, or fast errors)

Answer

Send every request directly to the DB because correctness matters more than availability

Answer

Queue every request until the cache returns

Answer

Automatically spin up a new cache and wait until it is fully warm

Question 11

When failing traffic over from region A to B, B's cache is warm only for local traffic. Which strategy most reduces overload risk?

Accepted Answer

Shift traffic gradually by weight, and keep B warm by replaying or shadowing part of A's traffic in normal operation

Answer

Shift 100% of traffic to B instantly and raise all of B's key TTLs

Answer

Flush B's cache before failover so old data is removed

Answer

Disable B's cache and serve everything directly from the DB

Question 12

With a primary DB in one region and replicas plus local caches in others, how should remote caches be invalidated?

Accepted Answer

Each region invalidates from its own local replica's change stream, so deletes happen after new data reaches that region

Answer

The writer service directly invalidates every cache worldwide right after commit

Answer

Never invalidate remote caches and rely only on TTL

Answer

All regions read from one shared central cache in the primary region

Question 13

A user in a non-primary region writes data (sent to primary) and immediately reads it. Facebook used a 'remote marker' for read-your-writes here. What is it?

Accepted Answer

A marker in the local cache signalling the local replica is behind for this key, so misses read from the primary until replication catches up

Answer

A header in the HTTP response telling the browser to refresh the page

Answer

A distributed lock that serializes concurrent writes to a key across all regions

Answer

Copying written data into every region's cache before committing on the primary

Question 14

In an active-active multi-region system, invalidations travel between regions via a queue and may arrive out of order. Which design keeps caches correct?

Accepted Answer

Idempotent invalidations (delete, not set) or sets carrying a version/logical timestamp so older messages cannot overwrite newer values

Answer

Using an exactly-once queue that guarantees global ordering

Answer

Synchronizing all server clocks with NTP and comparing wall-clock times

Answer

Sending each invalidation three times so at least one arrives correctly

Question 15

Why is a single Redis cluster shared across regions (e.g. app servers in Europe and the US) usually a bad design?

Accepted Answer

One region pays ~80–100ms of intercontinental latency on every hit, and an inter-region link outage takes away its cache

Answer

Redis does not allow clients in different time zones to connect

Answer

Redis corrupts data over long distances

Answer

A shared cluster always has a lower hit ratio than local caches

Question 16

A team stores feature flags and warehouse inventory in Cloudflare Workers KV. What have they overlooked?

Accepted Answer

KV is read-optimized and eventually consistent (propagation up to about a minute), so it does not suit inventory that needs consistency

Answer

KV only supports string values under 100 bytes

Answer

KV stores data in only one PoP and is unavailable elsewhere

Answer

KV forwards every read to the origin and adds latency

Question 17

A team moves SSR to the edge, but each render makes 5 sequential queries to a single-region DB. What is the likely result?

Accepted Answer

Latency gets worse because instead of one long round-trip there are five long round-trips from edge to DB

Answer

Latency drops to nearly zero because code runs near the user

Answer

The DB is automatically copied to the edge so queries become local

Answer

No difference, because the CDN network caches everything

Question 18

The origin uses `X-Forwarded-Host` to build script URLs in HTML, and the CDN does not include that header in the cache key. What attack is possible?

Accepted Answer

Web cache poisoning; the attacker plants a response with a malicious script via the crafted header, which is then served to everyone

Answer

Web cache deception; the attacker stores the victim's personal page under a static extension

Answer

DNS rebinding; the attacker changes the origin IP to their own server

Answer

HTTP request smuggling; the attacker merges two requests in one connection

Question 19

The CDN caches every URL ending in `.css`, and the framework maps `/account/settings/x.css` to the `/account/settings` page. What is the risk?

Accepted Answer

Web cache deception; the attacker lures the victim to that URL and their personal page gets publicly cached on the CDN

Answer

CSS injection; the attacker changes the settings page styles

Answer

Cache poisoning; the attacker stores a malicious CSS via a crafted header

Answer

No risk, because the settings page requires login

Question 20

Purging a widely used tag (e.g. `homepage`) across thousands of URLs spikes origin load. How does 'soft purge' help?

Accepted Answer

It marks content stale rather than deleting it, so it is served via `stale-while-revalidate` while revalidation happens gradually with coalescing

Answer

It postpones the purge until the next off-peak hour

Answer

It purges only content in low-traffic PoPs

Answer

It halves the content TTL instead of removing it

Question 21

A CMS purges the CDN immediately after saving an article, but the origin reads articles from a lagging read replica. What happens?

Accepted Answer

The request after the purge gets the old version from the replica and re-caches it in the CDN for the full TTL

Answer

The CDN holds the request until the replica catches up

Answer

The purge automatically forces the replica to sync immediately

Answer

The new version appears because purges read directly from primary

Question 22

A response is cached in Redis for 5 min, then in the CDN with `s-maxage=600` and in the browser with `max-age=300`. What is the worst-case staleness and why?

Accepted Answer

About 20 minutes, since each layer may grab a copy just before the layer below expires and TTLs add up

Answer

At most 10 minutes, since the largest TTL in the chain dominates

Answer

At most 5 minutes, since the shortest TTL applies to all layers

Answer

Zero, because every layer revalidates with the one below before serving

Question 23

In Varnish with request coalescing, a busy URL sometimes returns an uncacheable response (e.g. with `Set-Cookie`) and requests queue up serially. What does 'hit-for-pass/hit-for-miss' do?

Accepted Answer

It caches the 'do not cache this' decision for a while so later requests go to the backend in parallel without waiting in line

Answer

It force-caches the uncacheable response briefly for all users

Answer

It strips `Set-Cookie` and makes the response cacheable

Answer

It permanently disables coalescing for the whole server

Question 24

A news homepage gets 20K req/s and its content changes every few seconds. What does 'micro-caching' with a 1s TTL achieve?

Accepted Answer

Origin load drops from 20K to roughly one request per second per cache node, with at most one second of staleness

Answer

Almost no effect, because one second is far too short to cache

Answer

Origin load halves because half of the requests hit

Answer

Staleness reaches minutes because TTLs stack up

Question 25

Should a CDN cache origin `500` responses? Which policy is best?

Accepted Answer

Usually not, except with a very short TTL to shield a struggling origin, preferably serving the healthy stale copy via `stale-if-error`

Answer

Yes, with a long TTL so the origin is never contacted again during errors

Answer

Never; caching any non-`200` response is forbidden by the HTTP spec

Answer

Yes, but only in the browser and not on the CDN

Question 26

A video and its page go live to millions of users at the exact start of a live event. Which combination best protects the origin?

Accepted Answer

Pre-warming assets into the shield and key PoPs before launch, an origin shield, and request collapsing at every tier

Answer

Raising all file TTLs to one year at the moment of launch

Answer

Disabling the CDN and serving directly from origin to avoid staleness

Answer

Adding `Vary: Cookie` so each user gets a separate copy

Question 27

For live HLS streaming via a CDN, what is the right caching policy for the manifest (`.m3u8`) and segments (`.ts`)?

Accepted Answer

Segments immutable with long TTLs; the manifest with a very short TTL (about half a segment duration) plus coalescing

Answer

Both with long TTLs because video content does not change

Answer

Both `no-store` because live streams must not be cached

Answer

Manifest with a long TTL and segments with a very short TTL

Question 28

Users download 4GB files with range requests and seeking. Why do CDNs use 'slice/chunked caching'?

Accepted Answer

The file is split into e.g. 1MB slices cached separately so a small range does not require fetching all 4GB from origin

Answer

So large files are served directly from origin instead of the CDN

Answer

So each range request is stored under a completely new, independent cache key

Answer

So file size is halved by compressing each slice

Question 29

What problem with classic consistent hashing does 'consistent hashing with bounded loads' (used at Vimeo and Google) solve?

Accepted Answer

It caps each node at e.g. `(1+ε)` times the average load and spills extra keys to the next node on the ring

Answer

It removes the need for virtual nodes by using two independent hash functions

Answer

It guarantees no key moves when a node is added

Answer

It replicates data on every node so load is uniform

Question 30

How does rendezvous hashing (HRW) compare with a consistent hashing ring?

Accepted Answer

For each key it scores `hash(key, node)` for all nodes and picks the max; it is uniform without vnodes but lookup is `O(n)`

Answer

It sends each key to the node with the lowest network latency

Answer

Adding a node requires redistributing every key

Answer

It only works with a power-of-two number of nodes

Question 31

Google's Jump consistent hash uses no memory and distributes perfectly. What is its main limitation for a cache cluster?

Accepted Answer

Buckets can only be added or removed at the end, so removing an arbitrary middle node is not possible without broad remapping

Answer

It works only for numeric keys and does not support strings

Answer

Every key moves whenever a node is added

Answer

It requires a central coordinator to store the key map

Question 32

In a consistent-hashed distributed cache with vnodes, each key's replicas go on the next N ring positions. What is essential?

Accepted Answer

While walking the ring, skip vnodes of the same physical host (and ideally rack/zone) so replicas are truly independent

Answer

All replicas must live on one machine to keep latency low

Answer

Replica count must equal the number of vnodes per node

Answer

Replicas must be placed with a different hash function from the primary

Question 33

During Redis Cluster resharding, how does an `ASK` reply differ from `MOVED`?

Accepted Answer

`MOVED` means the slot moved permanently and the client should update its map; `ASK` means send just this request to the target (with `ASKING`)

Answer

`ASK` means the node is down and `MOVED` means the key was deleted

Answer

They are the same; the client should update its slot map in both cases

Answer

`MOVED` is sent only for writes and `ASK` only for reads

Question 34

In Redis Sentinel, the old primary keeps accepting writes from clients on its side of a partition while a replica is promoted. Which setting bounds the lost-write window?

Accepted Answer

`min-replicas-to-write` with `min-replicas-max-lag`, so a primary without healthy replicas rejects writes

Answer

`maxmemory-policy noeviction` so no data is ever removed

Answer

`appendfsync always` so every write hits disk

Answer

Increasing the number of Sentinels to an even count for more precise voting

Question 35

In a large cluster, one shard sporadically hits 100% CPU. How do you automatically detect and contain hot keys?

Accepted Answer

Sample accesses in clients or proxies with sketches like Count-Min/Top-K, and auto-promote hot keys to a local L1 or multiple copies

Answer

Run `KEYS *` on the shard every minute and count keys

Answer

Add more shards every time CPU spikes

Answer

Lower every key's TTL on that shard to one second

Question 36

You spread a hot key into 10 copies (`key#0..key#9`) across shards. What is the cost on the write path?

Accepted Answer

Every invalidation or update must reach 10 keys, and meanwhile readers may see inconsistent copies

Answer

No cost, since Redis keeps the copies in sync automatically

Answer

Writes go only to the first copy and the others are never updated

Answer

The shard count must equal the copy count exactly or errors occur

Question 37

Why does W-TinyLFU (in Caffeine) usually beat pure LRU on hit ratio in real workloads?

Accepted Answer

It has a frequency-sketch admission policy that admits a new key only if it is more popular than the victim, plus a small LRU window for bursts

Answer

It admits every key without limit and evicts only the largest ones

Answer

It uses TTLs instead of eviction so memory never fills

Answer

It automatically shards data across multiple machines

Question 38

Why does Redis use approximate LRU (sampling via `maxmemory-samples`) rather than exact LRU?

Accepted Answer

Exact LRU needs a linked list with extra pointers per key updated on every access; sampling gets close results with less memory and CPU

Answer

Because exact LRU is mathematically undefined beyond one million keys

Answer

Because approximate LRU always has a higher hit ratio than exact LRU

Answer

Because Redis does not store key access times at all

Question 39

Redis memory is high even though most keys have expired and are no longer read. Why?

Accepted Answer

Expired keys are removed lazily on access and by periodic active sampling, so untouched expired keys can linger and hold memory

Answer

Redis never removes expired keys unless `FLUSHALL` is run

Answer

TTLs are applied only on replicas, not on the primary

Answer

Expired keys are moved to disk and counted in memory stats

Question 40

A manager asks whether doubling cache memory is worth it. What is the best data-driven way to answer?

Accepted Answer

Build a miss ratio curve from real access traces (e.g. simulation or SHARDS) and compare miss reduction against memory cost and DB load

Answer

Doubling memory always halves the miss ratio, so it is always worth it

Answer

Check the average CPU usage of cache servers over the past week

Answer

Count the current keys and multiply by two

Question 41

Several services share one Redis cluster, and a nightly batch job writing millions of one-off keys wrecks everyone's hit ratio. What is the best structural fix?

Accepted Answer

Isolate workloads into separate clusters or pools with memory quotas, or stop caching the batch job's one-off data

Answer

Raise other services' key TTLs so they are evicted less

Answer

Run `FLUSHALL` after the batch job finishes every night

Answer

Switch eviction to `volatile-ttl` so batch keys go first

Question 42

A feed render fans out to 100 cache shards in parallel. Each shard's p99 is 2ms, but the request's p99 is 30ms. What is the cause and remedy?

Accepted Answer

With high fan-out some shard is almost always slow, so the request's p99 tracks shard tails; reduce fan-out via co-location or use hedged requests

Answer

Network latency between shards adds up because the requests are sequential

Answer

Redis serializes parallel requests from one client

Answer

Hit ratio is low and TTLs should be increased

Question 43

A team uses write-behind on Redis to record likes at 50K writes/s. Which design best preserves durability and correctness?

Accepted Answer

Append events to a durable log like Kafka or a replicated Redis Stream, with idempotent consumers batch-upserting to the DB by unique key

Answer

Keep counters only in Redis memory and flush hourly using `KEYS *`

Answer

Write every like directly to the DB and remove the cache layer entirely

Answer

Flush counters from Redis to the DB with `INCR` without tracking offsets or IDs

Question 44

Under GDPR a user's data must be deleted within a deadline. What is the role of cache layers in this design?

Accepted Answer

Every layer (L1, Redis, CDN, search index) must be purged or have TTLs below the legal deadline, and personal data must not sit in unpurgeable caches like browsers

Answer

Caches need no deletion since they are temporary copies and not the source of truth

Answer

Deleting the user's DB row is enough; caches update themselves

Answer

The entire cache must be flushed on every deletion request

Question 45

A dashboard has heavy aggregates taking 8s each and sparse access patterns, so cache-aside keeps missing. Which approach fits better?

Accepted Answer

Precompute (a materialized view or stream-updated aggregate table) and store results as primary data, not as a lazy cache

Answer

Raise the cache TTL to one week so misses decrease

Answer

Add more Redis memory so every combination fits

Answer

Enable request coalescing so concurrent misses merge

Question 46

A CDN fetched a `max-age=300` response 290s ago and now serves it to a browser with `Age: 290`. How long does the browser treat it as fresh?

Accepted Answer

About 10 seconds, since the current age is subtracted from `max-age`

Answer

A full 300 seconds from when the browser received it

Answer

590 seconds, since `Age` is added to `max-age`

Answer

Zero; any response carrying `Age` must be revalidated immediately

Question 47

A viral post's view counter using `INCR` on one Redis key has become a bottleneck. Which design scales the writes?

Accepted Answer

Sharded counters (`views:42:0..N`) on different slots, or local per-instance aggregation with periodic flushes; reads sum the shards

Answer

Replace `INCR` with separate `GET` and `SET` to reduce locking

Answer

Raise the counter key's TTL so it expires less often

Answer

Add replicas so writes spread across them

Question 48

Your architecture has a CDN in front of an origin that also caches responses in Redis. After a data change, in what order should invalidation happen?

Accepted Answer

Inside out: Redis first, then the CDN, so the CDN does not refetch the old version from Redis

Answer

Outside in: CDN first, then Redis, since the CDN is closer to users

Answer

Order does not matter because both expire eventually

Answer

Purge only the CDN; Redis empties itself on every CDN purge

Question 49

You placed a Bloom filter of existing IDs in front of the cache to stop penetration. Which operational issue must you design for?

Accepted Answer

New items must be added before becoming visible, and since deletes are impossible the filter accumulates false positives and needs periodic rebuilds

Answer

Bloom filters sometimes give false negatives and reject existing items, so the DB must always be checked too

Answer

The Bloom filter must hold whole objects, so it uses as much memory as the cache

Answer

Bloom filters only work with contiguous numeric keys

Question 50

A site using `Vary: Cookie` for homepage A/B testing has a near-zero CDN hit ratio. What is a better design?

Accepted Answer

Have the edge assign the user a bucket, derive a header like `X-Variant: B`, and key the cache only on that variant

Answer

Drop `Vary` and serve a random cached variant to every user

Answer

Move the whole cookie into the query string so the CDN keys on it

Answer

Disable the CDN for the homepage during the experiment