Notes from https://www.hellointerview.com/learn/system-design/core-concepts/caching
- Comes up often
- When database is getting hammered with reads
- Store frequently accessed data in fast memory to skip the database entirely for most reads
- Cache hit on Redis takes 1ms
- Typical database query 20-50ms
- 20-50x speed up
- Reduces load on database
- Handle more write traffic
- Avoid scaling prematurely
- Cache-aside with Redis
- Use 90% of the time
- On a read, check cache first
- If data is there, return it
- Caching introduces real complexity
- Hardest part is invalidation
- E.g user updates profile in database
- Need to delete or update cached copy
- Otherwise next read is stale
- Strategies
- Invalidate cache entry immediately after writes
- Use short TTLs and accept some staleness
- Combination
- Choice depends on how fresh data needs to be
- Cache stampedes
- When a popular cache entry expires, many concurrent requests all miss at the same time and pile onto the database to regenerate it
- Can spike database load and take down system
- Prevention
- Locking
- Only one request regenerates the entry while the rest wait
- Early recomputation
- Regresh entries before they expire
- Staggering TTLs
- Entries don’t all expire at once
- Full cache outage
- Redis goes down entirely
- Every request hits database
- Defenses
- Small in-process fallback cache
- Circuit breakers to shed load
- Graceful degradation until Redis recovers
- Common mistake
- Caching everything
- Cache only data that’s read frequently and doesn’t change often
- Profile system first, cache the hot paths
- CDN caching
- For static assets like images, videos, and JavaScript files served from edge locations close to users
- In-process caching
- Works for small values that change rarely
- Feature flags and config data
- Redis is default for core application data
Notes for https://www.hellointerview.com/learn/system-design/core-concepts/caching