How do you choose the TTL for a value you are caching in Redis? Walk through what actually drives the number, rather than defaulting to five minutes.

## The two forces Every TTL is a negotiation between **freshness** and **origin load**. Long TTL: fewer misses, less database traffic, more memory held, more staleness. Short TTL: fresher data, more misses, more origin work, and — if the miss path is expensive — more tail latency for the unlucky requests that hit an expired key. ## Force 1: the staleness budget Ask the owning team the blunt question: *how many seconds may a user see the old value before it is a bug?* Answers cluster into classes: - **Immutable / content-addressed** (rendered assets, versioned config, `sha256`-keyed blobs): no staleness possible; TTL exists only to reclaim memory, so hours or days, or no TTL plus an LRU eviction policy. - **Reference data** (country lists, catalogues, feature-flag snapshots): minutes to hours, because a late update is annoying, not wrong. - **User-visible mutable state** (profile, cart summary, counters): tens of seconds to a few minutes. - **Security-relevant state** (permissions, entitlements, revocation, ban lists): seconds, or event-driven invalidation only — a stale *allow* is a security incident, and no TTL is short enough to make caching a revocation safe by itself. - **Negative entries** ("this ID does not exist"): seconds, far shorter than positives. ## Force 2: the arithmetic of origin load For a working set of N distinct keys that are all requested more often than they expire, the steady-state refetch rate from expiry alone is approximately **N / T** per second. Ten thousand keys at a 300-second TTL is ~33 origin reads/s; the same keys at 30 seconds is ~333/s. That single formula turns "pick a TTL" into capacity planning: decide how much origin QPS the cache tier is allowed to generate, then solve for T. Add the miss traffic from cold keys, evictions, and deploys on top. ## Force 3: do you have invalidation? If the write path can delete or overwrite the cache entry when the source of truth changes, TTL stops being the freshness mechanism and becomes a **backstop** against the invalidations you will inevitably miss (a batch job that writes straight to the database, a failed delete, a bug). Backstop TTLs can be long — tens of minutes to hours — and the freshness guarantee comes from invalidation. If there is no invalidation path, the TTL is the entire contract and must equal the staleness budget. ## Force 4: memory and the working set TTL also decides how much of the key space is resident. `keys × average size` must fit comfortably under `maxmemory` with headroom; otherwise eviction starts making the decision for you, which is a worse, less predictable version of the same choice. If a longer TTL would blow the memory budget, the honest answer is a shorter TTL, a smaller cached representation, or more memory — not hoping eviction sorts it out. ## Measuring rather than guessing - `INFO stats` → `keyspace_hits` / `keyspace_misses` gives the hit ratio; track it per deployment, and per prefix if you shard namespaces. - `INFO stats` → `expired_keys` shows how much churn expiry is causing; `evicted_keys` above zero means memory, not TTL, is bounding residency. - Plot hit ratio against TTL from real traffic. The curve rises steeply and then flattens: past the knee, extra TTL buys staleness, not hits. Pick just past the knee, then trim toward the staleness budget. - Watch origin QPS attributable to cache misses, and the latency of the miss path — that is what a too-short TTL actually costs users. ## Practical defaults Do not carry one global number. Set a small table of TTL classes per key prefix (immutable / reference / mutable / sensitive / negative), make the value configurable without a deploy so you can react during an incident, apply jitter centrally so a batch of keys does not expire together, and treat any key written without a declared class as a defect.