Module 5: Caching
5.1 What is Cache?
Definition: A cache is a high-speed storage layer that holds a subset of data (usually the most frequently or recently accessed) so future
requests for that data can be served faster than hitting the original, slower source (database, disk, external API).
miss
Client Cache Database
Why it matters: Reduces latency (cache is typically in-memory, orders of magnitude faster than disk-based DB reads), lowers database
load, and cuts infrastructure cost by avoiding repeated expensive computation.
5.2 Redis
Definition: An open-source, in-memory key-value data store commonly used as a cache, session store, message broker, and lightweight
database, supporting rich data structures (strings, hashes, lists, sets, sorted sets).
Azure implementation: Azure Cache for Redis provides a fully managed Redis instance with tiers ranging from Basic to Enterprise (with
clustering, geo-replication, and active-active support).
5.3 Cache-Aside (Lazy Loading)
Definition: The application checks the cache first; on a miss, it reads from the database, then populates the cache for future requests.
App Cache DB
1. Check cache → miss
2. Read from DB
3. Write result into cache
4. Return result to caller
Trade-off: Simple and only caches data that's actually requested, but the first request after a miss is always slow, and stale data can
persist until TTL expiry or explicit invalidation.
5.4 Write-Through
Definition: Every write goes to the cache and the database simultaneously (or the cache writes through to the DB immediately), keeping
cache and DB always in sync.
Trade-off: Slightly higher write latency (writing to two places) but reads are always fresh — good for read-heavy systems needing strong
cache consistency.
5.5 Write-Back (Write-Behind)
Definition: Writes go to the cache first and are asynchronously flushed to the database later, improving write latency at the risk of data
loss if the cache fails before flushing.
Write-back is fastest for writes but riskiest for durability; typically paired with persistence/replication on the cache layer to reduce data-loss risk.
5.6 Cache Invalidation
Definition: The process of removing or updating stale cache entries so consumers don't read outdated data after the source changes.
Strategies: TTL-based expiry (simplest), explicit invalidation on write (delete/update the cache key when the DB record changes), and
event-driven invalidation (publish a change event that subscribers use to evict related cache keys).
Interview Q&A
Q: What's considered one of the two hardest problems in computer science?
A: Cache invalidation (along with naming things and off-by-one errors) — because deciding exactly when data is "stale enough" to refresh, across
distributed caches, is genuinely difficult to get right.
5.7 TTL (Time To Live)
Definition: A configured duration after which a cache entry automatically expires and is removed, bounding how long stale data can be
served without manual invalidation.
Real-world example: A weather API response might be cached with a 10-minute TTL — acceptable staleness for a use case where exact-
second freshness doesn't matter.
5.8 Distributed Cache
Definition: A cache spread across multiple nodes so that cached data is shared and consistent across many application instances, rather
than each instance keeping its own isolated local cache.
App Instance 1 App Instance 2 App Instance 3
Distributed Cache
(e.g., Redis Cluster)
Why it matters: Without a shared distributed cache, horizontally scaled applications (Module 1) would each hold separate, inconsistent
local caches, defeating the purpose of caching for consistency and hit-rate efficiency.
Azure implementation: Azure Cache for Redis in Premium/Enterprise tiers supports clustering to shard cache data across multiple nodes
for higher throughput and larger datasets than a single node can hold.
Module 5 Common Mistakes
Caching data that changes too frequently to benefit from caching; forgetting to invalidate cache on updates, causing stale reads; using local (in-
process) cache in a horizontally scaled app, leading to inconsistent responses depending on which instance handles the request; setting no TTL at all,
causing unbounded memory growth or permanently stale data.
Module 5 Practice Interview Questions
1. Compare cache-aside, write-through, and write-back — when would you use each?
2. How would you handle cache invalidation for a product price that changes in real time?
3. Why does a distributed cache matter more as an application scales horizontally?
4. What happens to your system's database load if the cache layer goes down entirely?