In this chapter
We'll separate two ideas that sound alike but genuinely aren't: TTL, a deliberate expiration clock set per entry, and eviction, what happens when a cache runs out of room — two independent real triggers, either of which can cause real problems on its own.
The Problem in Real Life
Sarah sketches two real, different reasons a cache entry might disappear. "There's the timer running out," she says, "and then there's something else entirely — the cache just being full."
Mike frowns. "Those sound like the same problem to me. The entry's gone either way."
Isn't 'the timer ran out' and 'the cache is full' basically the same situation?
Mike
Gone Because It's Old vs. Gone Because There's No Room
TTL — a deliberate expiration clock
A fixed duration assigned per entry — expires on principle once time is up, regardless of capacity.
Eviction — triggered by running out of room
A finite cache under capacity pressure removes something to make space — even a fresh, unexpired entry can go.
TTL & Eviction
An entry can leave a cache for two genuinely different real reasons: its TTL (time to live) ran out, or the cache is full and something had to go to make room — eviction. These trigger under completely different conditions, and confusing them leads to real, avoidable mistakes.
- TTL — a real, deliberate expiration clock. A TTL is a real, set duration assigned to a cached entry at the moment it's stored — "keep this for 60 seconds," "keep this for a day." Once that duration passes, the entry is considered stale on principle, whether or not anything about it actually changed, and whether or not the cache has any spare room at all. It's the concrete mechanism behind the time-based invalidation strategy from the last chapter.
- Choosing a real TTL is itself a real decision. Too short, and GreenMart pays the real cost of re-fetching or recomputing data far more often than the data actually changes — most of the real benefit of caching, given away. Too long, and GreenMart risks exactly what just happened: a customer seeing confidently wrong information for the entire remaining duration of that window. The right real TTL depends specifically on how often the underlying data changes and how costly it is to be wrong about it — GreenMart's stock count needed a genuinely short TTL (or, better, the event-based signal from the last chapter); a rarely-changing product description could safely use a much longer one.
- Eviction — a completely separate, real trigger: running out of room. Every real cache has a genuinely finite size — a fixed amount of memory, a fixed number of slots. Eviction is what happens when a new entry needs to be stored but the cache is already full: something already there has to be removed to make space, regardless of whether its own TTL has expired yet. An entry with 55 minutes still left on a 60-minute TTL can still be evicted early, simply because the cache ran out of room and something had to go.
- Why the difference genuinely matters. TTL answers "how long should this be trusted?" — a question about the data itself. Eviction answers "what do we throw away first when we're out of space?" — a question about capacity, with no opinion at all about whether any given entry is still fresh. A cache can suffer real problems from either side independently: a TTL set too long causes stale data even with plenty of free space; a cache too small causes real, valuable entries to be evicted constantly even with a perfectly reasonable TTL, forcing repeated, expensive re-fetches. The next chapter goes deep on exactly which entry a cache chooses to evict first, once it's genuinely out of room.
| Question | TTL | Eviction |
|---|---|---|
| What triggers it? | A fixed duration passing | The cache running out of room |
| What does it answer? | "Is this data still trustworthy?" | "What goes when we need space?" |
| Can it happen with room to spare? | Yes — expiry doesn't care about capacity | No — eviction only happens under real capacity pressure |
| Can a fresh entry be affected? | No — TTL only removes entries once their own time is up | Yes — even an entry with plenty of TTL left can be evicted early |
GreenMart now has both real, independent levers a caching decision actually involves: how long to trust an entry (TTL) and what to do when there simply isn't room for everything (eviction) — two separate real dials, not one.
Key Takeaway
TTL and eviction answer two genuinely different real questions — how long is this data still trustworthy, versus what do we throw away when we run out of room — and a cache can go wrong from either one independently, even when the other is set perfectly.
Why This Matters
Every cache GreenMart configures from here forward — the proxy in front of the storefront, a future application-level cache, even a CDN — needs both of these real dials set deliberately. Treating them as the same decision, the way Mike initially did, is exactly how a cache ends up either stale or thrashing, sometimes both at once.
GreenMart now understands TTL (a deliberate expiration clock) and eviction (a response to running out of room) as two genuinely separate real mechanisms. The next chapter goes deep on the real algorithms — LRU, LFU, and others — that decide exactly which entry gets evicted first.