Soft state
State that expires unless refreshed. It is cheap to keep, safe to lose, and right for presence, sessions and anything that describes the present moment.
Distribution
Learn it
"Who's online", "where's their cursor", "which server holds this connection": these describe the present. Storing them durably means a write on every change and cleanup after crashes. A client that disappears without saying goodbye leaves a ghost that's "online" forever.
Soft state is kept alive by periodic refresh and expires when refreshes stop.
- A client announces itself and repeats every n seconds, often piggybacked on heartbeats.
- The holder stores it with a TTL a few refresh intervals long.
- If the client vanishes, refreshes stop and the entry expires on its own. No cleanup protocol, and no permanent ghosts.
Work it out
Clients refresh presence every 10 seconds. A TTL of about 3 refresh intervals tolerates a couple of lost refreshes. About how many seconds is that?Check
The server holding presence restarts and loses it all. What happens?The same applies to rapidly superseded data like cursor positions and typing indicators: send it at most once, coalesce updates, keep only the latest. A lost update is replaced by the next one.
Quick reference
The same ideas, condensed for revision.
How it goes wrong
- Ghosts
- Presence without expiry shows departed users forever.
- Flapping
- A TTL barely longer than the refresh interval expires during normal jitter.
- Durable presence
- Writing cursor positions to a database on every move creates heavy write load for data nobody needs later.
Instead, consider
- Durable state with explicit cleanup
- The information must survive restarts and be auditable, such as 'last seen' timestamps.
- Derived from connection lifecycle
- One server holds all connections and can infer presence directly from them.
In practice
- Redis keys with TTL
- SET presence:doc:user … EX 30, refreshed by heartbeats.
- In-memory maps with timestamps
- Swept periodically on the owning server.
- Routing protocols, DHCP leases
- The same pattern in networking.
It assumes
- A short gap or brief staleness after a restart is acceptable.
- Producers refresh at a known interval, and expiry is a small multiple of it.
Explain it in your own words
Where you practise it
Further reading
Engineers describing it in systems they run.
- Timelines at Scale
Twitter (X) · Raffi Krikorian · Talk, Apr 2013
A talk on how home timelines were served: fan-out on write into a cache, what that costs for very large accounts, and why timelines are treated as rebuildable.
Related concepts
- Persistent connections
Long-lived connections such as WebSockets turn a stateless request tier into one that holds per-client state, with consequences for routing, deploys and failure detection.
- Delivery guarantees
At-most-once, at-least-once, and why 'exactly-once' is achieved by making duplicates harmless rather than by preventing them.
- Caching
Keeping a copy of data closer to where it is used, trading freshness and complexity for speed and reduced load on the source.