Cache-aside
Cache-aside
Gold
The app checks the cache first; on a miss it reads the database and stores the result in the cache. Writes go to the database and expire or remove the cached copy.
- Use when
- Read-heavy data · Data that may be slightly stale · When a cache outage must not break correctness
- Avoid when
- Data written often and rarely re-read · Data that must never be stale
- Trade-offs
- Simple and safe if the cache dies, but reads can be stale · Misses pay an extra hop · A cold cache sends a burst of load to the database
- Requires
- Cache basics: hit ratio, TTL, eviction, Databases: the system of record
3 objectives · 9 misconceptions
- predict Predict database reads per second from traffic and hit ratio.
- diagnose Spot stale reads after writes and choose between TTL and explicit invalidation.
- predict Predict what happens to the database right after the cache is flushed or restarted.
- Not true: A cache always lowers p99.
- Not true: With cache-aside, writes go through the cache.
- Not true: With cache-aside, the cache holds writes and sends them to the database later.
- Not true: Once warm, the cache stays warm.
- Not true: The hit ratio is the share of requests that reach the database.
- Not true: A TTL keeps cached data correct, so a write needs no delete.
- Not true: A cache only makes reads faster; every request still reaches the database.
- Not true: When the database is down, the cache serves nothing.
- Not true: A warm cache covers for a dead database.
Learn
Cache-asideFree with an account~10 minPractice
Launch dayFree with an accountmediumCheck
Station test-out80% to passStories here
Neighborhood
→Cache-aside→