sessions get a home and an eviction rule

The cheapest way to hold a login is a signed token the client carries. It is also the hardest to take back: revocation becomes a blocklist, and a blocklist is a second store with its own lifetime problem. The platform had token plumbing sketched into two browser applications and decided against the whole shape.

What replaced it is server-side session state: a record per login, carrying the business it belongs to, a last-seen timestamp and its own idle window; indexed for lookup by user so an account action can revoke every session at once, and scoped by business so one record cannot be read as another. Login creates the record, guards resolve and extend it, and both logout and the revoke-all path delete through the same store.

The interesting decision concerns expiry, and it is the absence of machinery. There is no sweeper. Expired records are removed on first touch, with the justification written where the next engineer will find it: an expired row can never authenticate, so its continued presence is a storage question rather than a security one, and a background task with its own lifecycle is more apparatus than the problem deserves.

The client halves lost their token handling entirely — no credential in browser storage, no refresh dance, cookie only — so the browser surface stopped being a place where a session could be persisted or lifted by accident.

What it proves: identity state was moved where it can be inspected, scoped and revoked, and the eviction strategy was chosen with its reasoning attached rather than by habit.