Cache-Aside

Concepts Covered

• Cache hit
• Cache miss
• Database fallback
• Cache population
• TTLs
• Invalidation
• Cache stampede
• Source-of-truth fallback

1. Intent

Cache-Aside reduces latency and database load by letting the application manage cache reads and writes explicitly.

The application checks the cache first. If the value is missing, it reads from the source of truth, stores the result in cache, and returns it.

The pattern is useful because it keeps the cache as a performance layer, not the authority. The database or durable store remains the source of truth.

2. The Problem Without This Pattern

If every read goes to the database, read-heavy systems can overload their source of truth.

In a URL shortener, every redirect would hit the link database:

GET /x7Kp9Q -> database lookup -> redirect

That is correct, but a viral link can turn the database into the bottleneck for the same repeated answer.

In a like system, every feed render might ask the edge store whether the current viewer liked each visible post. That can create many small reads for every page load.

Without a cache, the source database carries both correctness and repeated read pressure. Cache-aside lets the application keep hot answers nearby while still falling back to truth when needed.

3. How The Pattern Works

Read path:

read(key):
  value = cache.get(key)
  if value exists:
    return value

  value = database.get(key)
  cache.set(key, value, ttl)
  return value

Write path usually updates the source of truth first, then invalidates or updates the cache:

write(key, new_value):
  database.update(key, new_value)
  cache.delete(key)

The next read reloads the fresh value from the database.

This pattern is simple, but the details matter. TTL controls how long stale values can survive. Invalidation controls what happens when the source changes. Negative caching controls whether missing values are cached to prevent repeated database misses.

4. When To Use It

Use cache-aside when:

• reads are frequent
• cache misses can safely fall back to a source of truth
• the application can tolerate bounded staleness
• cache contents are derived from durable storage
• hot keys create repeated database reads
• the application needs control over cache keys and invalidation

Good examples:

• short-code to destination URL mappings
• viewer like state
• user profile snippets
• feature flags with TTL
• product catalog reads

5. When Not To Use It

Avoid or be careful with cache-aside when:

• stale data is dangerous
• every request needs strongly consistent data
• the source system cannot handle miss bursts
• invalidation rules are too complex
• cached permissions could grant unsafe access
• values are rarely reused

Cache-aside is not a magic performance switch. If the cache is cold, unavailable, or invalidated too aggressively, the database must absorb the misses.

6. Data And Operational Model

Operators should monitor:

• cache hit ratio
• cache miss latency
• database fallback rate
• stale data incidents
• hot keys
• eviction rate
• cache node saturation
• stampede events after expiration

Common operational controls:

• TTLs with jitter so many keys do not expire at once
• request coalescing so only one caller rebuilds a missing hot key
• stale-while-revalidate for safe data
• negative caching for known-missing values
• explicit invalidation after writes

The key operational risk is a cache stampede: many requests miss at once and all hit the database.

7. Failure Modes

• Stale cache values survive after source changes.
• Cache outage floods the database.
• Hot keys overload one cache node.
• Cache stampede occurs after popular keys expire.
• Negative results are not cached, causing repeated misses.
• Cache is treated as truth and hides source-of-truth corruption.
• Invalidation succeeds before a database write commits, causing old values to be reloaded.

8. Tradeoffs

Benefit	Cost
Lower latency	Stale data risk
Lower database load	Application owns cache logic
Simple mental model	Cache stampede risk
Works with many databases	Invalidation remains hard
Protects hot read paths	Miss bursts still hit the source

Cache-aside is often the right first caching pattern because it is explicit and understandable. Its main weakness is that the application must own the lifecycle of cached data carefully.

9. Related Systems And Concepts

• URL Shortener System
• Instagram Likes System
• Caching
• Hot Key Mitigation
• Eventual Consistency