How does Redis keep track of which keys carry an expiry, what does that bookkeeping cost, and can an individual field inside a hash expire on its own?

## The two dictionaries Internally a Redis database (`redisDb`) contains, among other things: - **`dict`** — the keyspace: key object → value object, for every key that exists. - **`expires`** — key object → `long long` absolute expiry in milliseconds, containing an entry **only** for keys that have a TTL. The key object is shared between the two tables rather than duplicated, so the marginal cost of making a key volatile is one hash-table entry (a bucket slot plus a small entry structure) — on the order of tens of bytes. For a million volatile keys that is a handful of megabytes: irrelevant at normal scale, worth knowing when you hold hundreds of millions of keys and are weighing whether *everything* needs a TTL. This structure explains several behaviors at once: - `TTL`/`PTTL` are O(1) lookups that subtract the current clock from the stored deadline. - `PERSIST` simply deletes the `expires` entry; the value is untouched. - Deleting a key removes entries from both tables. - `INFO keyspace` reports `db0:keys=…,expires=…,avg_ttl=…` — the two counts come straight from the two tables, which is why the ratio is such a useful health signal. - The `volatile-*` eviction policies draw candidates from `expires`, so a small table means a small eviction pool. - The background expiry cycle samples this table rather than scanning the whole keyspace — the detail of that cycle is its own topic; the relevant point here is that the table exists precisely to make "which keys can expire" cheap to enumerate. ## Expiry granularity: top-level keys only Because `expires` is keyed by the top-level key object, a TTL applies to the entire key. There is no way for `EXPIRE` to reach inside a value: a single list element, set member, sorted-set member or (before 7.4) hash field cannot carry its own deadline. `EXPIRE mysessionhash 60` kills the whole hash — every field with it. This surprises people modeling "a hash of user attributes where each attribute has a different lifetime" or "a set of tokens that expire individually". Two long-standing workarounds: 1. **One key per item.** `session:42:token` with its own TTL instead of a field inside `session:42`. Costs more keys and more `expires` entries, but you get real, server-enforced expiry and the items become independent eviction candidates. This is the default answer. 2. **A sorted set as an expiry index.** Store members in a `ZSET` scored by their expiry timestamp, then have a periodic job (or the read path) run `ZRANGEBYSCORE key -inf <now>` and `ZREM` the results. Nothing expires automatically — you are implementing expiry yourself — so the sweeper must actually run, and readers should filter by score to avoid serving logically-dead members between sweeps. ## Redis 7.4: hash-field expiration Redis 7.4 introduced per-field TTLs for hashes: - `HEXPIRE key seconds [NX|XX|GT|LT] FIELDS numfields field …` - `HPEXPIRE`, `HEXPIREAT`, `HPEXPIREAT` — the millisecond and absolute variants - `HTTL` / `HPTTL` — remaining time per field - `HPERSIST` — remove a field's TTL - `HGETEX` / `HGETDEL` in later 7.4+/8.x releases for read-with-TTL-change and read-and-delete Fields expire independently, and when the last field of a hash expires the key itself is removed. This finally makes the "hash of independently-expiring attributes" model native, and it is the modern answer to the workarounds above — but only if you are on 7.4 or newer, and only for hashes: lists, sets and sorted sets still have no per-element TTL. ## Practical guidance - **Do not TTL everything reflexively.** Every volatile key is an extra `expires` entry and, more importantly, changes eviction semantics under `volatile-*` policies. Give TTLs to data that is genuinely time-bounded. - **Watch the `keys` vs `expires` ratio** in `INFO keyspace` as a hygiene metric: a cache namespace drifting toward fewer expires means some write path is dropping TTLs. - **Prefer separate keys over emulated field expiry** on pre-7.4 servers unless the field count is huge and the read pattern really wants a single hash. - **Check your deployment's version before promising per-field TTLs** — managed Redis offerings lag upstream, and a design that assumes `HEXPIRE` fails hard on 7.2.