CHAPTER 5

Caching and Content Delivery

Trading memory for speed, and keeping cached data fresh.

Source: Chapter 5 PDF, pp. 1–7

Learning objective

Understand where caches fit, choose a read/write strategy, keep data fresh, prevent common cache failures, and measure the benefit.

Core PDF content

PDF page 11. What is caching? p. 1

Imagine thousands of shoppers opening the same product page. Without caching, the application may repeatedly fetch the same product details from the database. A cache stores a copy of data so it can be retrieved faster next time.

Figure 1: Cache hit: return the copy. Cache miss: read the source and optionally save a copy. — Figure 1. Cache hit: return the copy. Cache miss: read the source and optionally save a copy. · PDF p. 1

A cache is usually not the source of truth. If a cached price differs from the database, the design needs a way to refresh or invalidate the copy.

2. Where can caching happen? p. 1

Figure 2: Copies can exist at the browser, CDN, application, cache service and database layers. — Figure 2. Copies can exist at the browser, CDN, application, cache service and database layers. · PDF p. 1

	Layer	Example	Benefit
	Browser	Logo, CSS, JavaScript	Avoid repeated downloads.
	CDN	Images, video, public assets	Serve content closer to users.
	Application / Redis	Sessions, popular product data	Reduce repeated database queries.
	Database cache	Pages or query results	Reduce repeated database work.
Key idea: A cache can reduce latency and load, but freshness rules must match the business need. A product image can tolerate more staleness than a payment balance.

PDF page 23. How should an application use a cache? p. 2

Caching strategies determine how data is read and written. Start with the request path and then choose the simplest strategy that fits freshness and durability needs. Cache-aside

Figure 3: On a miss, the application loads the source and fills the cache. — Figure 3. On a miss, the application loads the source and fills the cache. · PDF p. 2

Good for: frequently read product details, profiles and other data that can be cached safely. Watch out: many concurrent misses can create a burst of database queries. Read-through The application requests data from the cache, and the cache system loads missing data from the source using a configured loader. This can simplify application code but requires cache support or integration. Write-through vs. write-back

Figure 4: Write-through coordinates a synchronous write path; write-back saves to the source asynchronously. — Figure 4. Write-through coordinates a synchronous write path; write-back saves to the source asynchronously. · PDF p. 2

	Strategy	Write behavior	Main trade-off
	Write-through	Update cache layer and source synchronously.	Can keep cache fresh after writes, but increases write latency and coordination complexity.
	Write-back	Cache accepts write; source is updated later.	Fast and can batch writes, but needs a durability and recovery plan.
	Write-around	Write directly to source; don't fill cache.	Avoids caching write-once data, but first read may miss.
Common starting point: Cache-aside with a TTL and delete-on-write. The application writes to the source, then invalidates the key so a later read can load the updated value. Handle concurrent writes and refill races carefully.

PDF page 34. What happens when the cache fills up? p. 3

Cache memory is limited. Eviction removes entries to make room; expiration ends an entry's allowed lifetime; invalidation makes an entry unusable because the source has changed. They are related but different operations.

Policy	What it removes	When it helps
LRU	Least recently used entry.	A common general-purpose default.
LFU	Least frequently used entry.	Popularity is stable; aging helps forget old hot items.
FIFO	Oldest inserted entry.	Simple policy, but may evict useful items.
Random	Random entry.	Simple and low overhead; hit ratio may be weaker.
TTL	Entry after its lifetime ends.	Bounds the age of cached data; often combined with an eviction policy.
ARC / 2Q / W-TinyLFU	Adaptive mixes of recency/frequency.	Can resist scans that would flush frequently used items.

5. Keeping cached data fresh p. 3

A product price changes from $10 to $8 in the database, but the cache still holds $10. Users may see an outdated price until the old value is refreshed or invalidated.

Figure 5: A common cache-aside write path: update the database, delete the cache key, then reload on a later read. — Figure 5. A common cache-aside write path: update the database, delete the cache key, then reload on a later read. · PDF p. 3

	Technique	How it works	Trade-off
	TTL	Entry expires after a chosen time.	Simple; data can be stale until expiration.
	Explicit invalidation	Delete or update a key when source data changes.	Fast, but every write path must be covered.
	Event-driven	Change events invalidate caches.	Can coordinate many services, but event delivery and replay need handling.
	Versioned keys	Include version in key or asset filename.	Excellent for static assets; old versions may remain until expiry.
	Stale-while-revalidate	Return acceptable stale value while refreshing.	Keeps latency low when business rules allow staleness.
Choose freshness intentionally: Set the allowed staleness based on the data. A profile image can often be cached longer than account balances or inventory availability.

PDF page 46. Common cache failure modes p. 4

Caching can reduce database load, but poor cache behavior can create a new bottleneck. Learn to recognize the symptoms and choose a targeted mitigation. Cache stampede

Figure 6: A popular key expires and many requests miss together, overwhelming the source. — Figure 6. A popular key expires and many requests miss together, overwhelming the source. · PDF p. 4

Problem	What happens	Mitigations
Stampede / thundering herd	Many requests reload the same expired key.	Single-flight / request coalescing, per-key lock, early refresh, serve stale while refreshing.
Cache penetration	Requests for nonexistent keys always miss and reach the source.	Validate input, rate-limit, cache confirmed misses briefly; Bloom filter where useful.
Cache avalanche	Many keys expire together or cache cluster fails.	Jitter TTLs, replicas, warm-up, circuit breaker, load shedding.
Hot key	One key gets more traffic than a node can handle.	Local cache, replicate/shard the hot key, coalesce requests.
Stale / inconsistent data	Concurrent update and cache refill races.	Delete-on-write, TTL, versioning, event invalidation, read-your-writes where needed.
Big keys / memory pressure	Large values or churn create latency and eviction churn.	Cap value size, compress or split values, monitor evictions and hit ratio.

7. What if the cache itself fails? p. 4

Figure 7: A controlled fallback avoids turning every cache miss into an uncontrolled database surge. — Figure 7. A controlled fallback avoids turning every cache miss into an uncontrolled database surge. · PDF p. 4

Do not make the cache a hard dependency without a plan. Use timeouts, circuit breakers and fallback behavior that respects database capacity. In some cases, degraded responses are safer than sending every request to the source.

PDF page 58. Redis vs. Memcached p. 5

Both are commonly used for in-memory data access, but Redis offers more data structures and operational features. Memcached is deliberately simple and often suits straightforward object caching.

Feature	Memcached	Redis
Data model	Simple key-value entries.	Strings, hashes, lists, sets, sorted sets and more.
Persistence	Primarily in-memory cache.	Optional snapshots and append-only log.
Scaling	Often partitioned by client or platform.	Replication and Redis Cluster.
Extra features	Simple, multithreaded cache design.	Counters, streams, pub/sub, scripts and other data operations.
Typical use	Plain object cache.	Cache, sessions, counters, leaderboards, selected queues.

Redis operations and distributed locks Redis commands are fast, but expensive operations on large collections can block work on the relevant shard. Choose data structures and operations that fit the workload. Simple Redis locks can be useful for best-effort coordination, but correctness-critical mutual exclusion may need stronger coordination and fencing tokens.

9. What is a CDN? p. 5

A Content Delivery Network (CDN) stores copies of content at distributed edge locations. When an image is available at a nearby edge, the user can receive it without fetching it from the original server every time.

Figure 8: On a cache miss, the edge fetches from origin, then can reuse the content for later requests. — Figure 8. On a cache miss, the edge fetches from origin, then can reuse the content for later requests. · PDF p. 5

Common CDN content includes images, video segments, JavaScript, CSS, downloads and some cacheable API responses. A regional origin shield can combine repeated edge misses and reduce traffic to the origin. Cache keys, privacy and security A cache key commonly includes the URL and selected request attributes. Headers such as Vary affect which responses can be shared. Private data requires careful cache rules and authorization; signed URLs or cookies may protect private media. CDN features can also include TLS termination, DDoS absorption and WAF rules.

PDF page 610. How do you measure whether caching helps? p. 6

A cache should be measured, not assumed to be useful. Start with hit ratio and combine it with actual latency, source load and eviction behavior. Cache hit ratio

Hit ratio = hits / (hits + misses). If 95 of 100 lookups find cached data, hit ratio is 95%. Effective latency example Assume cache hits take 1 ms, source reads after a miss take 50 ms, and the hit ratio is 95%. Ignoring other overhead:

0.95 x 1 ms + 0.05 x 50 ms = 3.45 ms average lookup time. Actual end-to-end latency also includes application processing and network time.

Figure 9: Record hits and misses, then compare latency and source load. — Figure 9. Record hits and misses, then compare latency and source load. · PDF p. 6

Metric	What it tells you
Hit ratio	How often lookups find data in cache.
Evictions per second	How frequently entries are removed to free memory.
Cache latency	How quickly the cache responds.
Origin offload	How much traffic the CDN/cache keeps away from the source.
p95 latency / errors	Slow-request experience and cache failures.

Size the cache around the working set - the data accessed frequently enough to benefit from remaining in memory - rather than assuming the whole dataset must fit. High evictions plus a low hit ratio may indicate an undersized cache or poor policy fit.

PDF page 7Chapter recap p. 7

A cache stores copies of data to reduce latency and repeated work on the source.
Cache-aside is a practical starting point; write-through, write-back and write-around have different consistency and durability trade-offs.
Eviction frees memory; TTL expires entries; invalidation responds to changes in source data.
Stampedes, penetration, avalanches, hot keys and stale data need different mitigations.
Redis offers more data structures and features; Memcached is a simple object cache.
CDNs serve content closer to users and reduce repeated origin traffic.
Measure hit ratio, latency, evictions, errors and origin offload, and plan for cache failure.

Check your understanding p. 7

Choose the best answer for each question, then review the answer key.

1. In cache-aside, what normally happens on a cache miss?

A. The cache returns the missing value
B. The application reads the source and may fill the cache
C. The database is automatically deleted

2. A popular key expires and thousands of requests hit the database together. What is this called?

A. Cache penetration
B. Cache stampede
C. Consistent hashing

3. Which is a common way to serve static images around the world efficiently?

A. A CDN
B. A database write-back cache
C. Sticky sessions

4. What does a 95% cache hit ratio mean?

A. 95% of entries never expire
B. 95% of lookups find the requested data in cache
C. The database is 95% available

5. Why delete a cache key after successfully updating the database?

A. A later read can fetch the current value
B. It guarantees zero latency
C. It permanently disables caching

Answer key and explanations

B. The application loads the data from its source and commonly saves a copy in the cache.
B. A cache stampede occurs when concurrent misses trigger redundant source requests.
A. CDNs serve cached content from edge locations closer to users.
B. Hit ratio is hits divided by total cache lookups.
A. Delete-on-write is a common invalidation pattern; concurrent writes and refill races still need care.

Review questions for this chapter have not been written and reviewed yet. The chapter text above is the full source content.

Try it

CDN / edge cache Cache (in-memory)CloudFront ElastiCache (Redis/Valkey)Cloud CDN Memorystore (Redis/Valkey)Front Door / Azure CDN Azure Cache for Redis

References

Chapter 5 PDF, pp. 1–7; figures 1, 2, 3, 4, 5, 6, 7, 8, 9.

Ch. 4 Ch. 6: Databases and Storage

Tip: use ← and → keys to move between chapters.