Your database is slow. You add a cache. Problem solved?

Not quite. Now you have two copies of the same data. When do you update the cache? When do you update the database? What if they disagree?

These questions led to four patterns. Each makes different trade-offs.

Cache-Aside (Lazy Loading)#

The most common pattern. Application talks to cache and database separately.

Read path:

  1. Check cache
  2. If hit, return data
  3. If miss, read from database
  4. Store in cache
  5. Return data

Write path:

  1. Write to database
  2. Invalidate cache (delete the key)
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#000000','primaryTextColor':'#00ff00','primaryBorderColor':'#00ff00','lineColor':'#00ff00','secondaryColor':'#000000','tertiaryColor':'#000000'}}}%% sequenceDiagram autonumber participant App as Application participant C as Cache participant DB as Database App->>C: GET user:123 C-->>App: MISS App->>DB: SELECT * FROM users DB-->>App: {user data} App->>C: SET user:123 App->>App: Return data

Why invalidate instead of update? Simpler. Updating cache on every write is wasteful if that data isn’t read often. Let the next read populate it.

Trade-offs:

  • Cache miss on first request (cold start)
  • Brief window of inconsistency between invalidate and next read
  • Application manages both cache and DB logic

This is what I use 90% of the time. It’s simple and gives you control.

Read-Through#

Similar to cache-aside, but the cache itself fetches from the database on miss.

Read path:

  1. Application asks cache for data
  2. Cache checks itself
  3. If miss, cache reads from database
  4. Cache stores the data
  5. Cache returns to application

The application only talks to the cache. The cache handles DB reads.

Trade-offs:

  • Cleaner application code
  • Cache needs to know how to query your database
  • Less flexibility in what gets cached

Works well with cache providers that support it natively. Your code just calls cache.get(key) and the cache figures it out.

Write-Through#

Every write goes to cache first, then cache writes to database. Synchronously.

Write path:

  1. Application writes to cache
  2. Cache writes to database (same transaction)
  3. Return success only when both complete
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#000000','primaryTextColor':'#00ff00','primaryBorderColor':'#00ff00','lineColor':'#00ff00','secondaryColor':'#000000','tertiaryColor':'#000000'}}}%% sequenceDiagram autonumber participant App as Application participant C as Cache participant DB as Database App->>C: SET user:123 C->>DB: UPDATE users SET... DB-->>C: OK C-->>App: OK

Trade-offs:

  • Cache is always consistent with DB
  • Higher write latency (two writes, one synchronous)
  • Every write updates cache, even if data is rarely read

Good for read-heavy workloads where consistency matters and you can tolerate slower writes.

Write-Behind (Write-Back)#

Write to cache immediately. Database update happens later, asynchronously.

Write path:

  1. Application writes to cache
  2. Return success immediately
  3. Cache queues the write
  4. Background process flushes to database

Trade-offs:

  • Fastest writes (just cache, return immediately)
  • Risk of data loss if cache dies before flush
  • Complex failure handling
  • Database might be stale for a while

I’ve seen this used for analytics and logging where speed matters more than durability. For user data? Too risky for my taste.

Which One to Use?#

PatternBest For
Cache-AsideMost use cases. Simple, flexible.
Read-ThroughWhen you want cleaner app code.
Write-ThroughRead-heavy, consistency matters.
Write-BehindWrite-heavy, can tolerate loss.

At Oracle, we used cache-aside for most services. The control was worth the extra code. When query times dropped from 200ms to 3ms, nobody complained about the pattern being “manual.”

What I’m Learning#

Caching seems simple until you realize it’s a distributed systems problem in disguise. Two copies of data. Two sources of truth. The same consistency trade-offs we’ve seen all month.

The pattern you choose determines your failure modes. Cache-aside fails open (miss goes to DB). Write-behind can lose data. Write-through is slow but safe.

Pick based on what failure you can tolerate, not what seems cleanest.

What caching pattern does your team use? Did you choose it deliberately or inherit it?