Introduction
Caching stores frequently accessed data in a fast, typically in-memory layer so that repeated reads avoid hitting a slower backing database. In cloud architectures this is often implemented with a managed in-memory store such as Redis or Memcached, sitting in front of a relational or NoSQL database. How the cache and the database are kept in sync depends on which caching pattern you choose, and each pattern makes a different tradeoff between consistency and latency.
Cricket analogy: A stadium keeps the day's scorecard on a digital board courtside instead of radioing the scorers' room every ball; the board is the fast cache, the scorers' room is the slower backing database.
Explanation
Cache-aside (also called lazy loading) is the most common pattern: the application first checks the cache; on a cache miss, it reads from the database, then populates the cache before returning the result. Writes typically go to the database and either invalidate or update the corresponding cache entry. This pattern is simple and only caches data that is actually requested, but it means the first request after a miss is slower, and there is a window where the cache can be stale if invalidation is not handled carefully. Write-through caching updates the cache and the database together as part of the same write operation, so the cache is always consistent with the database immediately after a write, at the cost of added write latency since both stores must be updated before the write is considered complete. Write-behind (or write-back) caching writes to the cache immediately and asynchronously flushes the change to the database later, giving very low write latency but introducing risk: if the cache fails before the flush completes, that data can be lost, and the database is briefly stale relative to the cache.
Cricket analogy: Cache-aside is like a scorer only pulling a batter's career average from the archive when a commentator asks, then jotting it on his notepad for next time; write-through is updating both the live board and the official record together the moment a run is scored, adding a beat of delay; write-behind is scribbling the run on the board instantly and mailing the update to headquarters later, risking a lost entry if the notepad is lost before the mail goes out.
Example
Cache-aside (read path):
GET /product/42
cache.get(42) -> miss
db.get(42) -> row
cache.set(42, row)
return row
Write-through:
UPDATE product 42
db.update(42, data)
cache.set(42, data) # done as part of the write, synchronously
Write-behind:
UPDATE product 42
cache.set(42, data) # immediate
queue.enqueue(flush 42 to db) # applied to db asynchronously laterAnalysis
The right pattern depends on your read/write ratio and tolerance for staleness or data loss risk. Cache-aside is a solid general-purpose default for read-heavy workloads where occasional staleness after a miss is acceptable. Write-through is preferable when the application cannot tolerate the cache and database disagreeing, even briefly, and can afford slightly higher write latency. Write-behind is useful for extremely write-heavy workloads that need very low write latency and can tolerate a small risk of data loss or eventual consistency between cache and database, such as counters or logging-style data where an occasional lost update is acceptable. Regardless of pattern, cache invalidation and choosing an appropriate expiration (TTL) policy remain among the hardest parts of a caching layer to get right.
Cricket analogy: For a franchise mostly reviewing past match highlights, cache-aside's occasional stale replay is fine; a live DRS review system needs write-through so the big screen and umpire's tablet never disagree; a ball-by-ball fan commentary feed can use write-behind since losing one tweet occasionally is tolerable for the speed gained.
Key Takeaways
- Cache-aside loads data into the cache lazily on a miss and is a common general-purpose default.
- Write-through updates the cache and database synchronously, favoring consistency over write latency.
- Write-behind writes to the cache first and flushes to the database asynchronously, favoring low latency but risking data loss.
- Technologies like Redis and Memcached implement the in-memory cache layer in these patterns.
Practice what you learned
1. In the cache-aside pattern, what happens on a cache miss?
2. Which caching pattern updates the cache and database synchronously as part of the same write?
3. What is the main risk of write-behind (write-back) caching?
4. Which technology is commonly used as an in-memory caching layer in cloud architectures?
Was this page helpful?
You May Also Like
Content Delivery Networks (CDNs)
Learn how CDNs cache content at distributed edge locations to cut latency, and how cache hits and misses work.
Managed Databases Overview
Learn what a cloud provider handles for you in a managed database service versus running your own database on a VM.
High-Availability Design
Design systems that stay up through redundancy and automatic failover, and understand what each additional 'nine' of uptime really costs.
Cost Optimization Basics
Learn concrete cloud cost-optimization levers such as right-sizing, reserved and spot instances, storage tiering, and auto-scaling.