Middle Distributed Caching & CDN Interview Questions (50 MCQs)

Question 1

What problem does an 'origin shield' solve in a CDN?

Accepted Answer

It routes misses from all PoPs through a middle tier so the origin gets one request instead of dozens

Answer

It protects the origin from SQL injection by filtering request bodies

Answer

It periodically pushes origin content to all PoPs so no misses ever happen

Answer

It hides the origin's real IP by constantly rotating DNS records

Question 2

Which PoP is usually chosen as the origin shield?

Accepted Answer

The PoP that is network-closest to the origin

Answer

The PoP that serves the largest number of end users

Answer

The PoP farthest from the origin so load is spread out

Answer

A random PoP that changes on every request

Question 3

What behavior does the `stale-while-revalidate=60` directive produce?

Accepted Answer

For 60s after expiry, the stale copy is served immediately while revalidation happens in the background

Answer

The response is cached exactly 60s and afterwards users must wait for the origin

Answer

The cache syncs with the origin every 60s regardless of requests

Answer

On origin errors, requests are rejected with `503` for up to 60s

Question 4

How does `stale-if-error` help system resilience?

Accepted Answer

If the origin returns `5xx` or is unreachable, the cache can serve the expired copy instead of an error

Answer

It caches every origin error response with a long TTL so the origin is not hit again

Answer

It automatically retries the request against a backup origin in another region

Answer

It removes origin errors from logs to reduce alerts

Question 5

How does 'request coalescing' (collapsed forwarding) work in a cache?

Accepted Answer

For concurrent misses on one key, only one request goes to origin and the rest wait for that response

Answer

Several small requests for different keys are sent to the origin in one batch

Answer

Responses for related keys are merged and stored in a single entry

Answer

Duplicate requests from one user within a short window are dropped

Question 6

What risk must be managed when using a distributed lock (e.g. `SET key NX PX`) to prevent a stampede?

Accepted Answer

If the lock holder crashes or stalls, others wait; so the lock needs a timeout and waiters need a fallback

Answer

The lock makes all requests hit the database at once, doubling load

Answer

Locks only work on local caches and cannot be implemented in Redis

Answer

The lock resets the TTL of all other cache keys to zero

Question 7

In cache-aside, why do teams usually delete the cache key after a DB write instead of setting the new value?

Accepted Answer

Because two concurrent writes may set the cache out of order; delete is simpler and idempotent

Answer

Because setting a value is always slower than deleting and doubles latency

Answer

Because distributed caches do not support overwriting an existing key

Answer

Because delete causes the DB to be updated automatically as well

Question 8

Which scenario causes lasting stale data even with 'write DB then delete key' in cache-aside?

Accepted Answer

A reader loads the old value from the DB, a writer updates and deletes, then the reader sets the old value into the cache

Answer

Two readers read the same key from the cache concurrently and both get a hit

Answer

The writer deletes the key and the next request misses and loads the new value from the DB

Answer

The key's TTL ends before the write and it expires naturally

Question 9

Which workload is the write-around pattern suited for?

Accepted Answer

Data written often but rarely read right after writing, such as logs

Answer

Data read many times immediately after writing, like a profile right after editing

Answer

Data that must be written with very low latency even at risk of loss

Answer

Data that only lives in the cache and never needs storing in the DB

Question 10

Which write-behind benefit makes it attractive for counters like view counts?

Accepted Answer

Coalescing many writes to one key and flushing them to the DB in batches

Answer

Guaranteeing every increment is immediately and durably stored in the DB

Answer

Removing the need for a database to hold counters entirely

Answer

Providing strong consistency across all database replicas

Question 11

A CDN's hit ratio is low because URLs include `?utm_source=...&fbclid=...`. What is the best fix?

Accepted Answer

Strip tracking params from the cache key or whitelist only params that affect the response

Answer

Raise every response TTL to one year so misses drop

Answer

Disable caching for all URLs that have a query string

Answer

Add `Vary: User-Agent` so variants are separated better

Question 12

Why is `Vary: User-Agent` usually a bad idea for CDN caching?

Accepted Answer

There are thousands of distinct User-Agent values, so the cache fragments and hit ratio collapses

Answer

Because browsers never send the User-Agent header

Answer

Because `Vary` only works with compression-related headers

Answer

Because it causes responses to leak between different users

Question 13

A page that shows the user's name based on a session cookie is served with `Cache-Control: public, max-age=300`. What is the main risk?

Accepted Answer

The CDN may serve one user's personalized page to other users, leaking data

Answer

The browser deletes the cookie because the response is `public`, logging the user out

Answer

The CDN rejects the request with `400` because a cookie is present

Answer

The page is never cached because the cookie is always part of the cache key

Question 14

What advantage do 'surrogate keys' (cache tags) offer in CDNs like Fastly?

Accepted Answer

They let you purge all responses related to an entity, like `product-42`, in one call

Answer

They encrypt cache keys so users cannot guess cached URLs

Answer

They assign a separate TTL per user based on subscription tier

Answer

They replace the need for an origin by storing content permanently at the edge

Question 15

How does invalidation via 'versioned keys' (e.g. `user:42:v7`) work in a distributed cache?

Accepted Answer

Each change bumps the version so reads build the new key; old keys age out via TTL or eviction

Answer

All versions of a key are kept in a list and the reader picks the newest

Answer

The cache reads the version from the DB and instantly deletes old entries

Answer

The version is encoded in the TTL so old keys expire sooner

Question 16

One Redis Cluster key gets 200K req/s due to a viral event. Which mitigation is most effective?

Accepted Answer

A short-lived in-process L1 cache, or copies of the key with random suffixes on several shards

Answer

Adding more shards to the cluster so load spreads automatically

Answer

Raising that key's TTL from 5 minutes to 1 hour

Answer

Switching the cluster eviction policy from LRU to LFU

Question 17

Why are virtual nodes (vnodes) used in consistent hashing?

Accepted Answer

So each physical node appears at many ring points, making load distribution more even

Answer

So each key is automatically replicated to every physical node

Answer

To remove the need for a hash function to place keys

Answer

So nodes can communicate without a network

Question 18

How does Redis Cluster distribute keys across nodes?

Accepted Answer

It maps keys to one of 16384 hash slots via `CRC16(key) mod 16384`, and slots are assigned to nodes

Answer

With a consistent hashing ring where each node has 256 virtual nodes

Answer

With a central coordinator server that records each key's location in a table

Answer

With `hash(key) % N` where N is the number of primary nodes

Question 19

When is Memcached a more reasonable cache choice than Redis?

Accepted Answer

When you only need simple key-value blobs and multithreaded per-node throughput matters

Answer

When you need data structures like sorted sets and streams

Answer

When the cache must persist to disk and recover after restart

Answer

When built-in replication and automatic failover between nodes are required

Question 20

In Redis, what is the difference between `allkeys-lru` and `volatile-lru` as `maxmemory-policy`?

Accepted Answer

`allkeys-lru` evicts from all keys; `volatile-lru` evicts only from keys that have a TTL

Answer

`allkeys-lru` removes only expired keys; `volatile-lru` removes any key

Answer

`volatile-lru` moves data to disk while `allkeys-lru` deletes it

Answer

They are the same but `volatile-lru` only applies on replicas

Question 21

An attacker keeps requesting random non-existent IDs and all hit the DB (cache penetration). Which combo is the best defense?

Accepted Answer

A Bloom filter of existing IDs in front of the cache, plus negative caching with a short TTL

Answer

Raise the TTL of all existing keys to several days so the DB is hit less

Answer

Add more replicas to the distributed cache

Answer

Switch the eviction policy from LRU to LFU

Question 22

How does a 'cache avalanche' differ from a single-key stampede?

Accepted Answer

Many keys are lost at once (mass expiry or cache outage) and the entire load shifts to the DB

Answer

Only one hot key expires and its requests reach the DB

Answer

Keys are gradually evicted one by one and hit ratio declines slowly

Answer

Stale data stays in the cache and is never invalidated

Question 23

Even for a fully uncacheable dynamic API, what benefit can routing through a CDN give?

Accepted Answer

TLS terminates at a nearby edge and warm connections plus optimized routes to the origin are used

Answer

The CDN automatically caches dynamic responses with a short TTL for everyone

Answer

The CDN runs the API logic at the edge so no origin is needed

Answer

The CDN batches requests and sends them to the origin together

Question 24

How can paid videos be cached on a CDN without anyone being able to share the link?

Accepted Answer

Use signed URLs or cookies with expiry, verified at the edge, with the signature excluded from the cache key

Answer

Set `Cache-Control: no-store` so every request goes straight to the origin

Answer

Add `Vary: Authorization` so each user gets a separately cached copy

Answer

Place videos on long random URLs that are hard to guess

Question 25

What problem do Edge Side Includes (ESI) or edge fragment composition solve?

Accepted Answer

Caching shared page parts with long TTLs while fetching personal or volatile parts separately

Answer

Compressing HTML at the edge before sending it to the browser

Answer

Automatically converting images to newer formats like WebP at the edge

Answer

Encrypting sensitive page parts so the cache cannot read them

Question 26

In a two-level architecture (in-process L1 plus Redis L2), what is the main challenge?

Accepted Answer

Invalidating L1 on every instance after a change, e.g. via pub/sub or a very short TTL

Answer

L1 is always slower than L2 because it serializes data

Answer

Redis does not allow data to be copied into the app process

Answer

L1 and L2 cannot have different TTLs

Question 27

Why do some teams drive invalidation from CDC (e.g. Debezium on the binlog) instead of app code?

Accepted Answer

Because every committed DB change, even from other services or scripts, triggers invalidation

Answer

Because CDC makes the cache strongly consistent with the DB with zero delay

Answer

Because CDC removes the need for TTLs on cache keys entirely

Answer

Because CDC is faster than any direct cache write

Question 28

What is the 'dual write' problem when an app updates the DB and then invalidates the cache?

Accepted Answer

If the process crashes between the two operations or invalidation fails, the cache stays stale until TTL

Answer

The DB is updated twice, creating duplicate data

Answer

Both cache and DB lock and a deadlock occurs

Answer

The invalidation causes the DB transaction to roll back

Question 29

A user edits their profile but immediately sees the old version because the CDN cached it. Which fix ensures read-your-writes for them?

Accepted Answer

For a short time after the write, bypass the cache for that user via a cookie/flag, or render the new version from the write response

Answer

Reduce all CDN response TTLs to one second

Answer

Disable the CDN entirely for profile pages

Answer

Ask the user to wait a few minutes and refresh

Question 30

Caching whole paginated query results (e.g. `products?page=3&sort=price`) versus individual objects: what is the trade-off?

Accepted Answer

Whole results give one fast hit, but invalidation is hard because one change affects many pages

Answer

Caching objects is always faster because it needs only one round-trip

Answer

Caching whole results needs no invalidation because pages never change

Answer

There is no difference; it only depends on the cache type

Question 31

In Redis with async replication, what happens if the primary dies after acknowledging a write but before sending it to the replica?

Accepted Answer

The replica is promoted to primary and that write is lost for good

Answer

Redis rejects all writes until the old primary returns

Answer

The write is automatically recovered from the AOF on the replica

Answer

The client receives a delayed error and resends the write

Question 32

There are 10M daily active users with ~2KB profile objects. If 20% of users produce 80% of requests, roughly how much cache memory is needed?

Accepted Answer

About 4GB plus data-structure and fragmentation overhead, so roughly 6GB

Answer

About 20GB because all daily users must be held

Answer

About 400MB because only 2% of the data is truly hot

Answer

About 40GB because each object must be copied to every node

Question 33

A CDN's request hit ratio is 95% but origin egress cost is still high. What is the likeliest reason?

Accepted Answer

Byte hit ratio is low; small files hit while large files like videos miss

Answer

The CDN also forwards hit requests to the origin for logging

Answer

A high hit ratio always increases egress cost

Answer

The CDN fetches files from the origin uncompressed

Question 34

Why is URL versioning usually better than CDN purging after each deploy for static assets?

Accepted Answer

Purges do not reach browsers or intermediate proxies and are not atomic, but a new URL bypasses every layer

Answer

Purging is extremely expensive per file in every CDN and is forbidden

Answer

Versioning reduces the file sizes

Answer

CDNs do not cache unversioned files at all

Question 35

Which Cache-Control strategy suits the HTML of a content site that uses hashed assets?

Accepted Answer

Short browser TTL (or `no-cache`), longer `s-maxage` on the CDN, plus purging on publish

Answer

`max-age=31536000, immutable` for HTML just like the assets

Answer

`no-store` on HTML so it is never cached

Answer

No header at all, leaving it to browser heuristics

Question 36

For a site with heavy long-tail content (millions of rarely visited pages), why does CDN tiered caching improve hit ratio?

Accepted Answer

Scattered requests from many edges aggregate at an upper tier, so a hit there is far more likely

Answer

Every edge pre-downloads all pages so no misses occur

Answer

The upper tier automatically extends page TTLs

Answer

Tiered caching shrinks each page through compression

Question 37

Compared with Anycast, what limitation does DNS-based (GeoDNS) PoP routing have?

Accepted Answer

Decisions use the resolver's IP rather than the user's, and rerouting depends on DNS record TTL

Answer

GeoDNS only works over IPv6 and does not support IPv4

Answer

GeoDNS requires each user to manually choose their PoP

Answer

GeoDNS sends all users to one central PoP

Question 38

What trade-off comes with storing user sessions only in Redis (no persistence)?

Accepted Answer

App servers become stateless with low latency, but losing Redis logs every user out

Answer

Session security increases but app servers need sticky sessions

Answer

Sessions never expire and memory grows without bound

Answer

There is no trade-off since Redis never loses data

Question 39

What problem does storing multi-megabyte objects in a single Redis key cause?

Accepted Answer

Redis is single-threaded, so reading or deleting a big value blocks other requests and saturates the network

Answer

Redis rejects any value larger than 1KB

Answer

Big values are automatically moved to disk and become slow

Answer

Big keys are never evicted and memory fills up

Question 40

Profiling shows Redis hits take ~5ms despite 0.3ms network latency. What is the likeliest bottleneck?

Accepted Answer

The app's serialize/deserialize cost for large objects (e.g. JSON)

Answer

Redis writes every hit to disk before responding

Answer

Key TTLs slow down lookups in Redis

Answer

Consistent hashing rebuilds the whole ring on each request

Question 41

Rendering a page needs 50 separate cache keys, each fetched with its own `GET`. What is the best optimization?

Accepted Answer

Fetch keys with `MGET` or pipelining to turn 50 round-trips into a few

Answer

Raise the TTL of all 50 keys to boost hit ratio

Answer

Move the keys to a separate shard with a stronger CPU

Answer

Wrap each `GET` in its own `MULTI`/`EXEC` transaction

Question 42

Which combination of metrics gives the best picture of a cache layer's health?

Accepted Answer

Hit ratio, p99 latency for hits and misses, eviction rate, memory use, and load reaching the origin

Answer

Only the average latency of all requests

Answer

Only the number of keys in the cache

Answer

Only the CPU usage of cache servers

Question 43

When is write-through a better choice than cache-aside with invalidation?

Accepted Answer

When data is read frequently right after being written and a post-write miss is expensive

Answer

When most written data is never read

Answer

When write latency must be as low as possible

Answer

When several services write directly to the DB without a shared layer

Question 44

Why can validating JWTs at the edge (e.g. with Cloudflare Workers) be useful?

Accepted Answer

Unauthorized requests are rejected before reaching the origin and protected content can be cached at the edge

Answer

JWTs no longer need signatures because the edge is trusted

Answer

The edge can silently renew expired tokens without the server knowing

Answer

Edge validation removes the need for HTTPS

Question 45

Why should negative cache entries usually have a shorter TTL than normal entries?

Accepted Answer

Because the item may be created soon and users should not see 'not found' for long

Answer

Because negative entries use more memory than normal ones

Answer

Because caches do not allow long TTLs for empty values

Answer

Because negative entries are replicated to every node

Question 46

Adding 3 nodes to a consistent-hashed Memcached cluster at peak hour: what is the risk and how is it reduced?

Accepted Answer

Part of the keyspace moves to empty nodes causing a miss wave; add nodes gradually, with low weight, or pre-warm them

Answer

No risk, because consistent hashing moves no keys at all

Answer

All keys are copied to the new nodes, doubling memory

Answer

The cluster must be fully flushed before new nodes are usable

Question 47

What does the refresh-ahead pattern do, and what data is it suited for?

Accepted Answer

Refreshes popular keys in the background shortly before expiry; suits hot data that is expensive to load

Answer

Reloads every key right after each DB write; suits rarely read data

Answer

Randomly predicts and loads keys before their first request; suits long-tail data

Answer

Restarts each key's TTL on every hit; suits data that never changes

Question 48

What does adding `immutable` to `Cache-Control: max-age=31536000` gain for hashed files?

Accepted Answer

The browser skips conditional revalidation requests for the file even when the user reloads

Answer

The CDN never purges the file even if a purge is requested

Answer

The file is stored on the browser's disk instead of memory

Answer

The origin is no longer allowed to change that URL's content

Question 49

What is the advantage of a proxy like mcrouter or Twemproxy in front of Memcached instead of client-side sharding?

Accepted Answer

Routing, failover, and topology changes are centralized and every language client behaves the same

Answer

Per-request latency drops because a network hop is removed

Answer

The proxy automatically persists data to disk

Answer

The proxy completely eliminates the need for consistent hashing

Question 50

An origin has three servers behind a load balancer and CDN revalidations almost never get `304`. What is the likeliest cause?

Accepted Answer

Each server generates a different `ETag` for the same file, e.g. based on inode or local build time

Answer

CDNs never send the `If-None-Match` header to origins

Answer

A `304` response is only valid for `POST` requests

Answer

The load balancer converts every `304` into a `200`