Cache-aside caching

Cache-aside: the app reads the cache, loads from the database on a miss and invalidates on write; simple, and the cache holds only what is read. Write-through: every write goes to the cache and the database together, so the cache is always warm but writes are slower. Write-behind: writes go to the cache and are flushed to the database later; fast, but data can be lost if the cache dies.

Let one request rebuild the value while others wait or get the stale value: a mutex or single-flight lock per key, early probabilistic refresh before expiry, and TTL jitter so many keys do not expire together.

When reads are frequent, data changes less often than it is read, the source is slow or expensive, and slightly stale data is acceptable. Measure first: caching adds complexity, staleness and failure modes, so it should solve a proven latency or load problem.

Base TTLs on how stale each data type may be and how often it changes: seconds for prices or stock, minutes for profiles, hours for reference data. Add jitter, combine with explicit invalidation on writes, and monitor hit rates and staleness complaints.

A reader misses, reads old data from the database, then a writer updates the database and deletes the key, and finally the reader writes the old value into the cache, which stays stale until expiry. Short TTLs, delayed double deletion, versioned values or write-through with compare-and-set reduce it.

Two concurrent writers can update the cache in the opposite order to the database and leave it permanently wrong. Deleting means the next read loads the committed value. Some teams delete twice (before and shortly after the write) to cover a read that races the commit.

Repeated requests for keys that do not exist bypass the cache and hit the database every time. Cache negative results briefly (store a 'not found' marker) and use a bloom filter of valid keys to reject impossible lookups early.

Many keys expiring at the same time, or the cache restarting empty, sends a flood of requests to the database. Prevent it with TTL jitter, warming the cache before traffic, request coalescing, and rate limiting or circuit breakers in front of the database.

When many requests miss the same key at once, only one fetches from the source while the others wait for its result (single-flight). It prevents duplicate work and stampedes on hot keys.

Caching domain objects by ID is easy to invalidate on writes. Caching query results (lists, search pages) is faster for reads but harder to invalidate, so use shorter TTLs or tag-based invalidation for them.

Use key versioning (include a version number in keys and bump it to invalidate a group), tag sets that list keys per tag, or namespaces with a generation counter. Avoid scanning for keys in production.

Serve the cached value even after it is stale while refreshing it in the background, so users get fast responses and data updates soon after. It suits data where brief staleness is fine.

A request may hit a browser cache, a CDN, an in-process cache (very fast, per instance) and a shared cache like Redis before the database. Each layer needs its own TTL and invalidation story; in-process caches are hardest to invalidate across instances.

Cache the stable parts, such as each item by ID, and cache the ordered list of IDs per page with a short TTL or a version key bumped on writes. Clients then fetch the ID page and hydrate items from the per-item cache, so one edit invalidates one item, not every page.

Replicate the hot key across several keys with a random suffix and read from one at random, add a small in-process cache with a short TTL in front of Redis, or use client-side caching. Detect hot keys from cache metrics or Redis' hotkeys sampling.

Use short TTLs, broadcast invalidation messages via Pub/Sub when data changes, or limit in-process caching to immutable or rarely changing data.

Estimate the working set (hot keys times average value size), add overhead for the data structure, and watch eviction and hit rates in production. A cache that constantly evicts hot keys is too small.

Highly sensitive data without encryption and access checks, per-user data under shared keys, data that must be strongly consistent (balances during payment), and errors without short TTLs.

Use compact formats (JSON for simplicity, MessagePack or Protocol Buffers for size and speed), compress large values, and include a schema version so deployments with changed shapes do not read incompatible data.

Preload the most requested keys before switching traffic (from logs or analytics), or let a canary serve traffic first. Warming avoids a cold-start spike on the database after deploys or failovers.

Cache-aside apps should treat cache errors as misses and read from the database, protected by timeouts, circuit breakers and rate limits so the database is not overwhelmed.

Track hit ratio, latency for hits and misses, eviction rate, memory use, key count and database load. A good cache shows high hit ratio for hot paths and reduced database QPS.

Write-through writes to the cache and database synchronously, adding write latency but keeping them consistent. Write-behind writes to the cache and flushes to the database later, which is fast but risks data loss if the cache fails before flushing.

Key the result by all its inputs, version each source, and invalidate when any source changes, often by including the source versions in the key. Prefer short TTLs when exact invalidation is impractical, and document the acceptable staleness.

Memcached suits a simple, multi-threaded key-value cache of small objects with LRU eviction and no persistence. Redis adds data structures, persistence, replication, pub/sub and Lua scripts, which you want for counters, leaderboards, rate limits or invalidation fan-out.

Cache the shared data without permissions applied, then apply the user's access check on every read, or include the permission scope in the key. Never cache a response filtered for one user under a key another user can hit.

Each reader recomputes a value slightly before its TTL ends with a probability that rises as expiry nears, so one request refreshes it early instead of many requests missing at once when it expires. It is a lock-free way to avoid stampedes.

Include the user or tenant ID in the key, apply the same authorisation as the source, avoid caching responses with personal data at shared CDN layers, and set Cache-Control: private for browsers.

The cache itself loads missing data from the database through a configured loader, so application code only talks to the cache. It centralises logic but ties the cache to the data source.

Cache-Control, ETag and Last-Modified let browsers and CDNs cache responses and revalidate cheaply, reducing load before requests even reach your application cache.

When a missing index, bad query or N+1 pattern is the real cause. Fix the query first; caching a slow query hides the problem and fails badly on cache misses.

Put a schema version in the key or value, deploy readers that understand both old and new formats, then writers that write the new one, and let old entries expire. Avoid a mass flush at peak, which would hit the database all at once.

1. AThe database
2. BThe applicationCorrect answer
3. CThe cache automatically
4. DThe load balancer

Why: The application reads the database and populates the cache itself; the cache knows nothing about the database.

1. AReturn a 500 to users
2. BRetry forever
3. CCrash the app
4. DTreat it as a miss and read the databaseCorrect answer

Why: The cache is an optimisation, not the source of truth.

1. AMore database replicas
2. BCaching negative results and bloom filtersCorrect answer
3. CLonger TTLs on real keys
4. DRemoving the cache

Why: This is cache penetration.

1. AOne request fetches while others wait for itCorrect answer
2. BEach request fetches separately
3. CRequests are dropped
4. DRequests are cached forever

Why: It prevents cache stampedes.

1. ANetwork partitions
2. BMemory fragmentation
3. CMany keys expiring at the same momentCorrect answer
4. DCache poisoning

Why: Staggered expiry spreads the reload work so the database is not hit by a wave of misses.

1. AMany keys expiring at onceCorrect answer
2. BOne slow query
3. CToo many replicas
4. DLarge keys

Why: TTL jitter spreads expiry.

1. AThe database
2. BDNS
3. CIn-process cachesCorrect answer
4. DRedis

Why: Each instance holds its own copy.

1. ABlocks until fresh
2. BDeletes stale data
3. CDisables caching
4. DServes stale data while refreshing in the backgroundCorrect answer

Why: Fast and eventually fresh.

1. ARestart Redis
2. BWait for TTLs
3. CBump a version number in their keysCorrect answer
4. DSCAN and delete all

Why: Old keys simply stop being read.

1. AWrite-behindCorrect answer
2. BWrite-through
3. CCache-aside
4. DRead-through

Why: Writes are flushed later.

1. ACountry lists
2. BBlog posts
3. CBalances during a paymentCorrect answer
4. DProduct descriptions

Why: Strong consistency is needed.

1. ADeleting the key
2. BA bigger database
3. CCopies under suffixed keys read at randomCorrect answer
4. DA longer TTL only

Why: Several copies put the reads on several nodes.

1. AKey eviction
2. BMany requests recomputing at the same momentCorrect answer
3. CAll cache hits
4. DData replication

Why: One reader refreshes early, before the crowd misses.

1. ARandom replacement only
2. BFIFO
3. Callkeys-lru or allkeys-lfuCorrect answer
4. Dnoeviction

Why: For a pure cache, allkeys-lru or allkeys-lfu evicts the least useful keys when memory is full.

1. ACDN settings
2. BBrowser version
3. CFont loading
4. DIndexes and query designCorrect answer

Why: Fix the root cause first.

1. ACache-Control: privateCorrect answer
2. BCache-Control: public
3. CETag
4. DVary: *

Why: Only the browser may cache it.

1. ATo compress data
2. BTo sort keys
3. CTo speed up Redis
4. DNew deploys may change the data shapeCorrect answer

Why: Prevents reading incompatible values.

1. AA database spike after a cold startCorrect answer
2. BData loss
3. CSlow writes
4. DLarge keys

Why: Preload the hot keys.

1. ATTL average
2. BHit ratioCorrect answer
3. CKey length
4. DNumber of servers

Why: Pair with database load.

1. AForever
2. BNever
3. COnly in the browser
4. DBriefly, with a short TTLCorrect answer

Why: The key may be created later.

1. AThe cache loads missing data itselfCorrect answer
2. BThe app writes to the database only
3. CData is never cached
4. DThe browser loads data

Why: A loader is configured in the cache.

1. ALarger caches
2. BDNS updates
3. CPub/Sub messagesCorrect answer
4. DLonger TTLs

Why: Each instance drops its copy.

1. AA CDN
2. BA browser cookie
3. CRedisCorrect answer
4. DMemcached

Why: Redis supports lists, sets, sorted sets, streams and persistence.

1. ANot at all
2. BOnly the first page forever
3. CItems by ID plus short-lived ID pagesCorrect answer
4. DEach full page forever

Why: An edit then invalidates one item rather than every page.

1. AAny of its sources changesCorrect answer
2. BOnly the first source changes
3. CNever
4. DThe server restarts

Why: Its correctness depends on every input.

1. AA key another user can readCorrect answer
2. BA versioned key
3. CA key with a TTL
4. DRedis

Why: That would leak one user's data to another.

1. AXML
2. BYAML
3. CCSV with headers
4. DMessagePack or Protocol BuffersCorrect answer

Why: Smaller and faster to parse.

1. AMisconfigured TTLs only
2. BToo smallCorrect answer
3. CToo large
4. DPerfectly sized

Why: Watch the eviction rate.

1. AThe user or tenant IDCorrect answer
2. BOnly the path
3. CThe server name
4. DA random number

Why: Prevents serving one user's data to another.

1. ABypass auth
2. BRevalidate cheaply with If-None-MatchCorrect answer
3. CSkip TLS
4. DCompress data

Why: A 304 avoids resending the body.

1. ATTL jitter
2. BCompression
3. CA slow reader re-populating the old valueCorrect answer
4. DTwo writers updating different keys

Why: Short TTLs or versioned values help.

1. ADisable the database
2. BVersion the key and let old entries expireCorrect answer
3. CFlush the whole cache at peak
4. DEdit values in place

Why: Gradual expiry avoids a stampede on the database.