Cache basics: hit ratio, TTL, eviction
Cache basics: hit ratio, TTL, eviction
Bronze
A cache keeps copies of often-used data in fast memory. Its value comes from the hit ratio; TTLs and eviction decide what stays and how stale it may get.
- Use when
- Read-heavy data that is expensive to compute or fetch · Data that can be briefly out of date
- Avoid when
- Data that is written often and rarely re-read · Data that must always be exactly current
- Trade-offs
- Freshness vs hit ratio · Memory cost vs backend load · One more component that can fail or start cold
- Requires
- Memory vs disk vs network
3 objectives · 6 misconceptions
- explain Explain what sets a cache's hit ratio — whether the same data is asked for again while the cache still holds it — and work out the load it leaves on the store behind.
- explain Explain how a TTL trades freshness against hit ratio, and what happens when an entry expires.
- choose Size a cache against the hot set its reads fall on, and choose an eviction policy — LRU, LFU or random — for the access pattern.
- Not true: A cache is a reliable place to keep data.
- Not true: Longer TTLs are always better because the hit ratio rises.
- Not true: When an entry's TTL runs out, the cache fetches a fresh copy from the store by itself, so the next read still hits.
- Not true: The hit ratio grows in step with the cache's size — a cache holding a fifth of the keys answers about a fifth of the reads, and doubling it doubles the hits.
- Not true: LRU is the best eviction policy whatever the access pattern.
- Not true: The hit ratio belongs to the cache — a number you configure, or one a warm cache reaches anyway — rather than something the traffic, the TTL and the cache's size decide.
Learn
Cache basics — hit ratio, TTL, evictionMembers~12 minPractice
No katas practice this yet.
Check
Station test-out80% to passNeighborhood
builds onMemory vs disk vs network
→Cache basics: hit ratio, TTL, eviction→