Caching Patterns – Cache-Aside vs. Write-Through

The “Just Cache It” Trap #

The most common performance band-aid in software engineering is: ” The API is slow? Just put Redis in front of it.”

This works for about 24 hours. Then, the inevitable happens: A user updates their profile, but the dashboard still shows the old name. The product manager screams “Bug!”, and the developer manually clears the Redis keys.

This isn’t a bug; it’s an architecture failure. Caching is not just optimization; it is Data Duplication. As soon as you introduce a cache, you step into the world of distributed consistency. If you don’t have a strict invalidation strategy, you are serving lies to your users.

The Core Logic: Who Owns the Write? #

There are two main philosophies on how to keep the cache and the database in sync. The difference lies in when the data gets into the cache.

1. Cache-Aside (Lazy Loading)

• The Logic: The Application is responsible for reading and writing to the cache. The cache doesn’t know about the database.
• The Flow: App checks Cache. If null, App reads DB, populates Cache, and returns data.
• Pros: Resilient. If Redis dies, the app just falls back to the DB (though it might be slow).
• Cons: The “Stale Window.” If you update the DB but fail to update the cache (or another thread reads the old value before your write finishes), the cache remains stale until the TTL (Time To Live) expires.

2. Write-Through (Synchronous)

• The Logic: The Application treats the Cache as the primary writer.
• The Flow: App writes to Cache and DB at the exact same time (or Cache writes to DB).
• Pros: Strong Consistency. The cache is never stale because it is updated immediately upon write.
• Cons: Write Latency. Every write operation now pays the penalty of two network calls. Also Cache Pollution—you might be caching data that is written once and never read again.

Architecture Diagram: The Flow Difference #

graph TD
    subgraph "Cache-Aside (Standard)"
    App1[Application] -- 1. Get(Key) --> Cache1[(Redis)]
    Cache1 -- Miss --> App1
    App1 -- 2. Read DB --> DB1[(Database)]
    App1 -- 3. Set(Key, Val) --> Cache1
    end

    subgraph "Write-Through (Consistent)"
    App2[Application] -- 1. Write(Key, Val) --> Wrapper[Cache Wrapper]
    Wrapper -- 2a. Update Cache --> Cache2[(Redis)]
    Wrapper -- 2b. Update DB --> DB2[(Database)]
    note[Both must succeed to return OK]
    end

The Logic Check: Decision Matrix #

Do not default to Cache-Aside just because it’s easier.

The “Thundering Herd” Problem #

A hidden danger of Cache-Aside is the Thundering Herd.

• Scenario: You have a “Daily Deal” product page. The cache key expires at 12:00:00.
• The Event: At 12:00:01, 5,000 users request the page simultaneously.
• The Crash: All 5,000 get a “Cache Miss.” All 5,000 hit the Database at the exact same millisecond. The Database crashes.
• The Fix: Request Coalescing (or Locking). Only allow one thread to fetch from the DB; the other 4,999 wait for that one thread to repopulate the cache.

Real-World Case Study: Facebook (Meta) #

Facebook is the king of Cache-Aside (using Memcached). They faced a massive “Stale Sets” problem.

• Problem: When a user updated their location, the “Write” would clear the cache. But a concurrent “Read” (from a friend viewing the profile) might load the old value from a Replica DB and re-fill the cache with the stale data.
• Solution: They invented Leases. When a client gets a cache miss, Memcached gives it a “Lease” (a ticket). Only the client holding the lease is allowed to write to the cache. If you have stale data, you don’t have the lease, so Memcached rejects your update.

Conclusion #

Cache invalidation is one of the two hardest problems in Computer Science (naming things is the other). The Golden Rule: Always set a TTL (Time To Live). No matter how good your invalidation logic is, bugs happen. A TTL ensures that even if your logic fails, the stale data eventually dies.