Caching Interview Questions

Summary

Cache-aside: the application reads the cache, and on a miss loads from the database and populates the cache. Read-through: the cache itself loads missing data. Write-through: writes go to the cache and the store synchronously. Write-behind: writes go to the cache and are flushed to the store asynchronously.

Longer Answer

Cache-aside is the most common (Redis + app code) because it's simple and the cache only holds requested data; the app invalidates or updates the key on writes. Write-through keeps cache and store consistent at the cost of write latency. Write-behind gives fast writes but risks data loss if the cache fails before flushing, so it's used for counters or analytics, not money.

Code Example

def get_product(product_id: int) -> dict:
    key = f"product:v2:{product_id}"
    if (cached := redis.get(key)) is not None:
        return json.loads(cached)
    product = db.fetch_product(product_id)          # miss → source of truth
    redis.set(key, json.dumps(product), ex=300)      # populate with TTL
    return product

def update_product(product_id: int, data: dict) -> None:
    db.update_product(product_id, data)
    redis.delete(f"product:v2:{product_id}")         # invalidate after the write

Key Points

• Cache-aside: app-managed, most common
• Read-through: cache loads on miss
• Write-through: synchronous dual write
• Write-behind: async, risk of loss

Comparison / Tradeoffs

Summary

Invalidation is hard because data changes in many places, caches are distributed, and races between reads and writes can repopulate stale values. Strategies: TTLs as a safety net, delete-on-write, versioned keys, event-driven invalidation, and accepting bounded staleness where the business allows.

Longer Answer

A classic race: request A misses and reads the old value from the DB; request B updates the DB and deletes the key; request A then writes the stale value into the cache. Mitigations include short TTLs, delayed double delete, versioned keys (bump product:v{n}), or write-through with compare-and-set. Decide per data type how stale is acceptable.

Key Points

• TTL as safety net
• Delete on write
• Versioned keys
• Events for cross-service invalidation
• Define acceptable staleness

Summary

A stampede happens when a popular key expires and many concurrent requests miss at once, all hitting the database to recompute the same value, which can overload it. Prevent it with request coalescing/locks, early (probabilistic) recomputation, stale-while-revalidate, and jittered TTLs.

Longer Answer

Options: (1) a short lock (SET key:lock NX EX 5) so only one request recomputes while others wait or serve stale; (2) refresh before expiry with probability increasing as expiry nears (XFetch); (3) serve the stale value while one background task refreshes; (4) add random jitter to TTLs so many keys don't expire together.

Key Points

• Many misses on one hot key
• Single-flight locks
• Early/probabilistic refresh
• Stale-while-revalidate
• TTL jitter

Summary

Cache-Control tells browsers and CDNs whether and how long to cache (public, max-age=300, private, no-store, s-maxage, stale-while-revalidate); validators (ETag, Last-Modified) let clients revalidate with conditional requests and receive 304 Not Modified; CDNs cache responses at edge locations close to users.

Longer Answer

Static assets with hashed filenames can be cached for a year with immutable. API responses that are personalized must be private or no-store. Vary tells caches which request headers change the response (e.g., Accept-Encoding). Purge or use short TTLs plus surrogate keys for content that changes.

Code Example

# Static, fingerprinted asset
Cache-Control: public, max-age=31536000, immutable

# Public API response, revalidate in the background
Cache-Control: public, max-age=60, stale-while-revalidate=300
ETag: "v42-9f8e"

# Personalized response
Cache-Control: private, no-store

Key Points

• Cache-Control directives
• ETag/Last-Modified + 304
• CDN edge caching
• private/no-store for personalized data
• Vary header

Summary

Penetration: requests for data that doesn't exist bypass the cache every time. Breakdown (stampede): one hot key expires and many requests rebuild it at once. Avalanche: many keys (or the whole cache) disappear at once and the database takes all the load.

Longer Answer

Fixes differ: negative caching and Bloom filters for penetration; request coalescing, locks, early refresh or stale-while-revalidate for breakdown; TTL jitter, bounded database fallback, replication/persistence and warming for avalanches.

Key Points

• Penetration: missing keys
• Breakdown: one hot key expires
• Avalanche: mass loss/expiry
• Different protections for each

Deep dive: Database Caching at Scale

Summary

The stale-set race: a reader misses and reads the old row, a writer commits and deletes, then the reader sets the old value — which stays until the TTL. Leases or version-checked sets prevent it; short TTLs bound it.

Longer Answer

Facebook's memcache paper introduced leases for exactly this ('stale sets') and for thundering herds. In Redis, store a version with each value and set only if newer in a Lua script.

Key Points

• Reader set lands after the delete
• Leases / versioned sets
• Short TTLs as a bound

Deep dive: Database Caching at Scale

Summary

If a personalized response lacks Cache-Control: private, no-store (or the CDN ignores origin headers), the shared cache stores it by URL and serves it to the next visitor. Mark personalized responses private, make the CDN respect headers, and don't cache responses with Set-Cookie/Authorization.

Longer Answer

Split pages into a shared, cacheable shell and client-loaded personalized parts; add automated checks that authenticated endpoints return private/no-store.

Key Points

• Shared caches key by URL
• private, no-store for personal data
• CDN must respect origin headers

Deep dive: Database Caching at Scale

Summary

Keys should be deterministic, namespaced, versioned and include every input that changes the result (tenant, locale, user/role when personalized, query parameters), while staying reasonably short.

Longer Answer

Example: catalog:v3:tenant:42:product:1001:locale:en. Versioning lets you change the cached format without collisions. Hash long inputs (search queries). Forgetting an input (like tenant or permissions) causes data leaks between users.

Key Points

• Namespace + version
• Include every varying input
• Hash long inputs
• Missing tenant/user = data leak

Summary

If cache keys or HTTP caching rules don't include the user, tenant or permissions, one user's data can be served to another, a serious data leak. CDNs caching authenticated responses are a common source of such incidents.

Longer Answer

Mark personalized responses Cache-Control: private or no-store, include tenant/user in application cache keys, and test cache behavior with multiple users.

Key Points

• Keys must include identity
• private/no-store for user data
• Beware CDNs on authenticated routes
• Test with multiple users

Summary

Identify read-heavy, expensive or latency-sensitive paths and their staleness tolerance; pick the closest safe layer (CDN for public content, Redis for shared computed data, local cache for config); define keys, TTLs, invalidation and stampede protection; and estimate hit ratio, memory size and the load the database must still handle.

Longer Answer

State failure behavior (cache down), consistency guarantees (eventual, read-your-writes) and how you'd monitor effectiveness.

Key Points

• Target hot, expensive reads
• Choose the layer by audience
• Keys, TTLs, invalidation
• Capacity and failure plans

Summary

After. Deleting before commit lets other readers re-cache the old row (they still see it until the commit). Use on-commit hooks or transactional events.

Longer Answer

Django transaction.on_commit, Laravel DB::afterCommit, Spring @TransactionalEventListener(AFTER_COMMIT) or a transaction-aware cache manager. Also avoid filling the cache from a lagging replica right after a write.

Key Points

• Invalidate after commit
• Before-commit deletes get undone
• Don't fill from lagging replicas

Deep dive: Database Caching at Scale

Summary

After a soft expiry, the cache keeps serving the old value while one background refresh rebuilds it, avoiding stampedes and latency spikes. It's inappropriate for data that must be exactly current, like stock at checkout or permissions.

Longer Answer

Available in HTTP (Cache-Control: stale-while-revalidate), in libraries (Caffeine refreshAfterWrite, Laravel Cache::flexible) and easy to build with a soft-expiry timestamp inside the value.

Key Points

• Serve stale, refresh once
• Prevents stampedes
• Not for must-be-fresh data

Deep dive: Database Caching at Scale