A deadline that slides.

A session usually should expire after a period of inactivity, not at a fixed time after sign-in. A learner reading a long page for forty minutes should not be logged out mid-read because their session was born forty-one minutes ago. That is the case for a sliding deadline.

An absolute deadline is one EXPIRE session:abc123 1800 at sign-in. The key dies thirty minutes later regardless of activity. It is the right choice when a hard session cap matters — a banking session that must end on a fixed schedule whatever the user does.

A sliding deadline runs the same EXPIRE session:abc123 1800 after every read. HGETALL to read the record, then EXPIRE to push the deadline a full window past now. While requests keep arriving inside the window, the deadline keeps moving and the session stays alive. The moment requests stop, the last EXPIRE stands, and the key dies one window after the final request. Active users stay in; idle ones fall out.

A deadline is a promise, not an instant deletion. When a key’s TTL passes, the engine does not stop the world to delete it that second. It reclaims an expired key two ways, and knowing both is what makes a TTL real.

Lazy eviction happens on access: when a command touches a key whose TTL has passed, the engine detects the lapsed deadline, deletes the key, and responds as if it were absent — a GET returns nil, an HGETALL returns empty. The expired key is reclaimed exactly when it is next asked for. Active eviction runs in the background: the engine periodically samples keys that carry a TTL and deletes the ones that have expired, so a key that is never read again does not sit in memory forever.

For a session this matters in one way: an expired session is functionally gone the instant a request reads it, because the read lazily evicts it and returns nothing. The application never receives a stale session. The active sweep is what keeps abandoned sessions — the ones no request ever returns to — from leaking memory. Pick a key state below to see which mechanism reclaims it and what the next read returns.

EchoCache writes its L2 row with the TTL in the same command — SET ecc:{<table>}:<id> (version<>value) PX ttl_ms (table.ex:290) — so value and deadline land atomically; a session is a TTL’d row and the PX expiry is its lifetime. A re-put on the next request re-stamps the row with a fresh deadline, the sliding-window move.

Above L2, the L1 ETS copy carries its own expiry drawn from a jittered clock — expires_at/1 returns ttl ± ttl·jitter (table.ex:484) — so a cohort filled together never expires together, and a separate :sweep handler (table.ex:350) reclaims the dead rows on a fixed tick with one :ets.select_delete. Two clocks, each layer sovereign over its own staleness. The functional-Elixir and OTP craft behind the cache is the /elixir course; this dive is the deadline the store enforces.

A session deadline is absolute when it is fixed at sign-in and sliding when an EXPIRE after each read pushes it a full window past now. Sliding keeps active users in and lets idle ones fall out. The engine makes the deadline real two ways: lazily, deleting an expired key the instant a command reads it, and actively, sweeping never-read expired keys in the background. EchoCache adds a jittered L1 clock and its own sweeper. The next dive binds this deadline to the namespace it belongs to — keyed by a branded id, dropped on logout, refused at the kind gate.