Backend Engineering Interview Concepts for Production Part 4:Caching and Cache Invalidation on AWS

Why cache repeated database reads?



How does cache-aside work?



key = "product:v1:42:USD:US"

product = cache.get(key)
if product exists:
    return product                  # cache hit

product = database.readProduct(42)  # cache miss
cache.set(key, product, ttl=60 seconds)
return product

What is cache invalidation?



What is a TTL, and does it refresh the cache?

Which cache write strategy should you use?

Can database-first invalidation still return stale data?



What is a cache stampede?



How do negative caching and eviction work?

Negative caching remembers a confirmed absence

Eviction removes entries to make room

When should you cache data?

Which caching metrics should you monitor?

How does caching work on AWS?



Follow one AWS request

Secure the cache and network path

Send cache metrics through Lambda logs

Invalidate changes from other writers

Where do CloudFront, RDS, Aurora, and DAX fit?

Account for the full AWS cost

Build a small caching project

Common caching interview questions and answers

How would you keep cache and database reasonably consistent?

Failure to prevent: I want to avoid serving stale data after a successful database change. Mechanism: I would keep the database as the source of truth, update it first, then invalidate every affected cache key. Cache entries would also have TTLs as a backup. If several systems can write the data, I would process database change events and make invalidation idempotent. Critical decisions such as checkout would bypass the browsing cache or validate against the authoritative path. Trade-off and observation: The database and cache are separate systems, so brief staleness and race windows remain. I would monitor invalidation failures, event delay, cached age or version, source comparisons, and stale-data incidents.

What is a cache stampede and how would you prevent it?

Failure to prevent: I want to stop many requests from rebuilding the same expired value and overwhelming the database. Mechanism: I would coalesce requests so one worker refreshes a hot key while others wait for its result. Across application instances, I would use a short shared lease with ownership, expiry, bounded waits, and a failure fallback. TTL jitter spreads expiry across different keys, and stale-while-revalidate can help when an older value remains safe. Trade-off and observation: Coordination adds latency and failure modes, while serving stale data is not safe for every path. I would monitor misses per key group, concurrent source reads, database throttling, refresh time, lease timeouts, and p95 latency during expiry.

When should you not cache data?

Failure to prevent: I want to avoid added cost, stale decisions, and a cache that provides little benefit. Mechanism: I would skip the cache when source reads already meet the target, requests have little reuse, data changes faster than it is read, or the decision requires current authoritative state. I would fix the real bottleneck first if it sits in images, frontend code, or another service. Trade-off and observation: Going without a cache sends more reads to the source but keeps the design smaller and removes cache-consistency work. I would watch source latency, capacity, cost, read reuse, and error rates, then add caching only if measurements support it.

A concise caching answer for interviews

Repeated product reads can increase latency and database load, so I would consider cache-aside for reusable browsing data. A hit returns the copy; a miss reads the source and fills the cache. I would update the database first, invalidate affected keys, and use TTLs as a backup. I would account for delayed readers, stampedes, eviction, and cache outages. Checkout would use authoritative validation rather than trusting the browsing cache. In production, I would compare end-to-end latency, source load, hit rate, invalidation failures, and freshness against the extra cost and complexity.