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. One device key cannot represent multiple instances. Lease each instance and aggregate per device, removing expired scores during reads.
Data design covers atomic writes, concurrent access, schema migration, crash recovery, and cleanup. One successful save says nothing about power loss, full storage, or reopening with an older version.
Engineering boundaries and tradeoffs
Turn the important choices into durable contracts: validate inputs, assign state ownership, define cleanup, and specify fallback for older peers. Later optimization must not change those semantics.
- Lua renews instance TTL and device zset together, keys share a cluster hash tag, and periodic authoritative scans emit offline while keyspace notifications only accelerate.
- Separate protocol facts, user intent, and automatic recovery; automation may restore facts but never overturn an explicit choice.
- Use explicit capability negotiation so older clients receive an explained fallback instead of a half-working state.
The delivery standard for Modeling Presence in Redis with Expiry, Sets, and Atomic Scripts 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
Boundaries turn hidden assumptions into incidents. Weak networks, refresh, concurrency, and capacity need combined coverage because retries can hide each one in isolation.
- Relying on expired notifications leaves ghosts when events are disabled or lost, while full scans of large sets block Redis.
- Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
- 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.
- Toggle notifications, kill nodes, move slots, churn tabs, and delay scans; final presence must match active leases without blocking spikes.
- 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.