ProgramGuru

Cache-Aside Pattern

Cache-Aside: start from the problem

See the responsibilities

ApplicationChecks an eligible cache key
Cache missRequires an authoritative read
DatabaseSupplies the source value
Cache fillStores a replaceable copy
Application: Checks an eligible cache key → Cache miss: Requires an authoritative read → Database: Supplies the source value → Cache fill: Stores a replaceable copy

A product page repeatedly reads the same description. The database remains authoritative, but repeating that eligible lookup consumes work. The application can keep a disposable copy and fill it when needed.

This is a data and messaging pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.

What you’ll learn

  • Explain the problem Cache-Aside addresses and the roles involved.
  • Follow the example and distinguish this pattern from nearby alternatives.
  • Choose when the benefit justifies the extra responsibilities and testing.

How the responsibilities work

In Cache-Aside, the application checks the cache first. On a miss, it reads the authoritative store, puts an eligible copy in the cache and returns the value. The application therefore owns the coordination between those two stores.

The example uses local Maps and shows one database read for two requests. It intentionally has no expiration, concurrent fills or failure timing. A price or permission requiring current authority may need a different read path.

Follow a small example

Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.

JavaScript · local teaching example

const cache = new Map();
const database = new Map([['P1', 'Blue mug']]);
let reads = 0;
function readProduct(id) {
  if (cache.has(id)) return cache.get(id);
  reads++;
  const value = database.get(id);
  if (value !== undefined) cache.set(id, value);
  return value;
}
console.log(readProduct('P1'));
console.log(readProduct('P1'));
console.log('database reads=' + reads);

Expected output

Blue mug
Blue mug
database reads=1

Choose a design and inspect the consequence

Compare the design choices

Many requests miss the same popular key at once.
A response contains private account data.

Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.

This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.

Use the consequences to explain your decision, including the simpler alternative.

Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.

When it helps—and what it costs

Use it for reusable reads whose freshness and permissions fit a cached copy. The cache must be allowed to miss or disappear without losing the authoritative record.

Old values, concurrent refills and simultaneous cold misses need deliberate policies. Write-then-invalidate still has races if an older in-flight read can refill afterward. Bound fill concurrency and do not describe this sequential example as a distributed atomic protocol.

Distinguish the neighbouring patterns

Cache-Aside puts read/fill coordination in application code. Read-through products can provide that boundary as a cache feature. Cache-write policies decide what happens to authoritative updates.

Follow cache hits, misses and eviction, concurrent invalidation races, write-through and write-behind policies to compare the specific responsibility before combining patterns.

For further reading, use Microsoft’s Cache-Aside guidance. Compare it with this original example and the guarantee required by your application.

Check your pattern reasoning

Which record is authoritative in this example?
Choose one answer. You can try again.

Answer and explanation

The database record.

The cache is a replaceable copy.

Check your pattern reasoning

Does a cache hit prove a value is current?
Choose one answer. You can try again.

Answer and explanation

No; freshness depends on the policy and intervening updates.

A reusable copy can be old.

Name the responsibility before choosing the pattern

For Cache-Aside, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.

Return to the design-pattern guide to compare families, or apply the idea alongside write-through and write-behind policies.

Reaching the recap and completing the quizzes are separate milestones.

    Next lesson: Write-Through and Write-Behind Patterns →