Caching
Also known as:
Cache
Caching Strategies
Definition
Caching keeps a copy of expensive-to-fetch data in a fast store so most reads avoid the slow source. The main strategies differ in who fills the cache and when: cache-aside (the app loads on a miss), read-through (the cache loads on a miss), write-through (write to cache and store together), write-behind (write to cache, flush to store later), and write-around (write straight to the store). The hard parts are eviction and invalidation, keeping the cache fresh enough without serving stale data.
Popular reads
View All
Payment System Design: Ledger, Idempotency, and Settlement
Jul 18, 2026
The Complete HTMX Guide: From Zero to Production
Dec 22, 2025
How Google manages billions of lines of code in one monorepo
Sep 04, 2026
Cursor Skills: How to Create and Use Agent Skills
Jun 23, 2026
Transactional Outbox Pattern: Never Lose an Event Again
Apr 07, 2026
Flash Sale System Design: Architecture, Scale, and Oversell
May 16, 2026
Key Takeaways
- Cache-aside is the most common pattern: the application reads the cache, falls back to the database on a miss, and populates the cache.
- Write-through keeps cache and store in sync on every write; write-behind is faster but risks losing buffered writes.
- Eviction (usually LRU) bounds memory; invalidation keeps entries from going stale, and getting it wrong is a classic bug.
- An expiring hot key can trigger a thundering herd, so add jitter or request coalescing.
How It Works
- On a read, check the cache first; a hit returns immediately from fast memory.
- On a miss, load from the source, return it, and store it in the cache with a TTL.
- On a write, update or invalidate the cached entry according to the chosen strategy.
- Evict entries with a policy like LRU when the cache is full.
Where It Is Used
- Redis and Memcached are the default in-memory caches for web backends.
- CDNs cache static assets and responses close to users at the edge.
- Read replicas and materialised views are database-level caching of query results.