TTL (time to live)
How long a cached or stored value stays valid before it must be refreshed or discarded.
A TTL bounds staleness. It appears in caches, DNS records, session stores and message queues, and it always encodes the same trade: a short TTL means fresher data and more load, a long one means the reverse. The important question is what happens at expiry — whether the value is refreshed, recomputed on demand, or simply gone.
Full guide:
How long an idempotency key stays valid, and what happens when it expires
— Twenty-four hours is the common default and it is chosen to outlive any retry a client will attempt. Below roughly one hour, a late retry after a network partition is treated as a new operation and duplicates the work. Above about seven days the table grows without bound for no additional protection, because no client retries a week later.
Key facts
- TTL trades freshness against load: halving it roughly doubles the work of recomputing the value.
- Identical TTLs set at the same moment expire together, producing a thundering herd — spreading them with jitter avoids the synchronised miss.
- A TTL measured from write rather than from last access will expire a hot entry that is still in constant use.
- Expiry is usually lazy: a value may sit in storage past its TTL and only be discarded when something next asks for it.
Frequently asked questions
What TTL should I use?
Start from how stale the data may safely be for the reader, not from how expensive it is to compute. A price that must be correct within a minute has a one-minute TTL however cheap it is to fetch.
What is a cache stampede?
Many requests missing the same expired key at once and all recomputing it together. Jittered TTLs, or letting one request refresh while others serve the stale value, both prevent it.
Machine-readable copy of this page:
/glossary/ttl.md