Skip to content

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

0 of 2 checks done
  1. "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.
  2. 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?
    seconds

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

Write at least 60 characters (0 so far). Write it as you would say it in a design review. You will compare it against the points a strong answer makes.

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.

  • 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.