System Design · Module 6 · Lesson 1 of 4 · 40 min

Cache Placement Read Paths and Write Strategies

Choose where a cache belongs, trace cache-aside, and compare read-through write-through write-back and write-around responsibilities.

A cache design starts with the cost it removes, the authoritative store and the freshness contract.

01 The idea

The problem this lesson solves

The app needs one code-to-destination mapping.

Prerequisite: earlier lessons introduce the vocabulary and shared examples used here. Follow the module order.

Source of truthThe authoritative state used to decide the correct durable value.

Cache-asideThe application checks the cache and loads the backing store on a miss.

Write-backAcknowledging a cached write before persisting it to the backing store under the chosen contract.

02 Worked example

Follow one worked example

App: Requests a7 • Cache: Hit: return copy • Database: Miss: load truth • Fill: Store eligible result.

Trace the example in order. Follow the same identities, units and state transitions through the diagram and the events below.

Request a7The app needs one code-to-destination mapping.

Check the cacheA hit returns the permitted copy; a miss is a separate branch.

Load the authorityOn a miss, read the database and distinguish absent from unavailable.

Fill for reuseWrite an eligible value with its freshness policy for later requests.

A cache design starts with the cost it removes, the authoritative store and the freshness contract.

03 The method

Mechanisms decisions and a guided tutorial

Work through the explanation in order, then apply it in the tutorial. Each comparison names a cost as well as a benefit.

Choice or concept	Purpose	Boundary or cost
Cache-aside	Application loads misses	Concurrent fill and invalidation races
Write-through	Write path maintains cache and store	Cross-system partial failure still needs a contract
Write-back	Persistence is deferred	Pending changes can be lost without durable recovery
Write-around	Write directly to backing store	Existing cached copies still need a policy

Choose where the copy belongs

Browser caches avoid some network requests; CDNs place eligible responses near users; local process caches avoid a separate cache-service hop; a distributed cache is shared by app instances. Each has different invalidation and privacy boundaries. Cache keys must include every input that changes the response, such as tenant, authorization scope, locale or data version when applicable. Omitting a tenant identifier can turn a fast lookup into another tenant's data.

Trace cache-aside explicitly

The application looks up the key. On a hit it returns the value. On a miss it reads the database, stores the result with an expiry, and returns it. An absent key is not the same as an empty string or zero; represent missing values deliberately. Cache-aside can be introduced without making the database depend on the cache, but the application now owns freshness and concurrent-fill behavior.

Read and write strategies move responsibility

In read-through, a cache abstraction loads missing values for the application. In write-through, the write path updates the backing store and cache before acknowledging according to its contract; two independent writes are not automatically atomic. Write-back acknowledges before persisting to the backing store, so durability and recovery of pending changes become critical. Write-around bypasses the cache for writes and must still address existing stale entries. Choose from the required durability and freshness, not from the name that sounds fastest.

Choose a boundary, not just a product

A browser cache can avoid a network request. A CDN can avoid a trip to the origin. A local process cache avoids a separate cache-service hop but has one private copy per process. A distributed cache shares entries across the app pool but becomes a network dependency.

State what the cached representation means and which inputs change it. A cache key for a localized tenant resource may need tenant, resource id, language and version. Authorization-sensitive output needs a deliberately safe policy. A hit on the wrong representation is a correctness defect, even if it is very fast.

Trace both hit and miss

For code a7, first look up the cache. On a hit, return the permitted copy. On a miss, read the database, store the result with the chosen expiry and return it. The database does not automatically populate a cache-aside store; the application owns that work.

Distinguish missing from legitimate empty or zero values. A negative cache entry represents an authoritative “not found” observation and needs its own lifetime and creation invalidation behavior. A dependency timeout is not an authoritative negative result and should not be cached as absence.

Write responsibility changes the risk

Read-through moves loading behind the cache abstraction. Write-through coordinates backing-store and cache updates before acknowledging according to its contract. Two separate network writes are not magically atomic. Write-back defers backing-store persistence and therefore needs durable handling of pending changes if loss is unacceptable.

Write-around bypasses the cache for writes but must still address any existing cached old value. Compare strategies using failure cases: one write succeeds, the other times out; the cache restarts; a reader overlaps an update. A faster happy path is not enough to choose the strategy.

Guided tutorial

1. Draw both branches

Label hit and miss arrows and the payload on each.

2. Write a cache key

Include tenant and representation inputs where required.

3. Name the writer

For each write strategy, state which layer updates which store.

4. Break one dependency

Explain the response when only one of two writes succeeds.

value = cache.get(scoped_key)
if value is present:
    return value
result = authoritative_store.lookup(code)
if result is a cacheable authoritative result:
    cache.set(scoped_key, result, ttl)
return result

04 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

Choice or concept	Remember	Check
Cache-aside	Application loads misses	Concurrent fill and invalidation races
Write-through	Write path maintains cache and store	Cross-system partial failure still needs a contract
Write-back	Persistence is deferred	Pending changes can be lost without durable recovery
Write-around	Write directly to backing store	Existing cached copies still need a policy

Source of truthThe authoritative state used to decide the correct durable value.

Cache-asideThe application checks the cache and loads the backing store on a miss.

Write-backAcknowledging a cached write before persisting it to the backing store under the chosen contract.

05 Where & why

Check the primary references

Use official references for protocol and implementation details. The questions here are teaching prompts.

Primary reference

Redis eviction policies

Read Redis eviction policies

Primary reference

Redis SET

Read Redis SET

Primary reference

Redis TTL

Read Redis TTL

Primary reference

HTTP stale-while-revalidate

Read HTTP stale-while-revalidate

State the implementation version and the workload assumptions when defending your own design.

06 Interview questions

Explain the reasoning out loud

Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.

What does Source of truth mean?

The authoritative state used to decide the correct durable value.

What does Cache-aside mean?

The application checks the cache and loads the backing store on a miss.

What does Write-back mean?

Acknowledging a cached write before persisting it to the backing store under the chosen contract.

Why not cache an origin timeout as not found?

The timeout does not establish absence. Caching it as a negative result can hide valid data and turn an outage into persistent wrong answers.

How does local cache differ from distributed cache?

Local cache avoids a network hop but each process has its own copy and cold-start behavior. A distributed cache shares entries while adding a dependency and network cost.

Who loads a cache-aside miss?

The application explicitly reads the authoritative store and fills the cache. The cache service does not infer that relationship.

Is write-through automatically atomic?

1. Place the cache

A CDN with a correct public/versioned cache policy can avoid origin downloads; browser caching can remove later network requests too.

2. Name the authority

The durable order store is authoritative under this design. The cache is a representation with an explicit freshness rule.

3. Build a key

Include tenant id, product id, locale and any version needed by the invalidation policy. Authorization and cache eligibility remain separate checks.

4. Partial write

Specify acknowledgment, retry identity and invalidation/recovery behavior. Do not claim atomic success across the two independent operations without coordination.

5. Negative result

Reads can keep returning missing until invalidated or expired. Choose short negative lifetimes and creation-path invalidation where appropriate.

6. Strategy review

Cache-aside can suit replaceable summaries with bounded staleness. An acknowledged financial state needs explicit durable authority and recovery; an evictable pending copy without those guarantees is not a sufficient write contract.