The dangerous implementation is not one that never works. It is one that works in a demo and loses its boundaries under real networks and real data volume. Presence is recent evidence, not permanent truth. Store expiresAt, instanceId, and connection count, then derive online, suspect, and offline from server time.
A real-time backend needs coherent semantics for identity, ordering, backpressure, and reconnects. Every message needs a session version, replay rule, and bounded outcome for slow consumers.
Engineering boundaries and tradeoffs
List non-negotiable invariants before selecting performance knobs. Tuning can roll out gradually; identity, permission, and terminal-state rules cannot drift at runtime.
- Jitter heartbeat intervals and make the lease span several cycles; send best-effort leave on clean close and use atomic counts so closing one tab does not mark the device offline.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.
The delivery standard for Presence Is Not a Boolean: TTLs, Heartbeats, and Offline Decisions is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
How it fails in production
Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.
- Equal heartbeat and TTL values flap on one scheduler delay, while client clocks make expiry vulnerable to drift and tampering.
- A stale response arriving after a new task can overwrite healthy state or restart cancelled work without version fencing.
- An untested fallback receives all traffic during a primary failure and becomes the slower, more expensive bottleneck.
Turn testing into a closed loop
Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.
- Freeze a tab, unplug networking, kill a process, roll the service, and close one parallel tab; measure suspect and offline timing for each.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.
A capability becomes maintainable when it degrades safely, repetition adds no side effects, and its signals reveal a fault before user reports do.