The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. A WebSocket belongs to one process, but the business session need not. A leased directory maps devices to instances while durable state remains authoritative.
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.
Make the implementation decisions explicit
List non-negotiable invariants before selecting performance knobs. Tuning can roll out gradually; identity, permission, and terminal-state rules cannot drift at runtime.
- Treat affinity as an optimization; route acknowledged cross-instance commands and rebuild a failed instance from authoritative state plus a session cursor.
- Define success, degraded, cancelled, and failed terminal states before UI, storage, and metrics consume the same state.
- Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.
The delivery standard for Stateless or Sticky Signaling: Decide by State Ownership 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.
Failure paths that are easy to miss
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.
- Using an in-memory Map as the session database loses reject, cancel, and idempotency records, while hard cookie affinity blocks regional recovery.
- 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.
How to verify it before release
Write the expected state trace before injecting faults. At every phase, reconcile user-visible outcome, both protocol endpoints, persistent records, and resource counts to prove the loop.
- Kill nodes holding both peers, one peer, or idle sockets; recovery semantics must match and no ghost presence may remain.
- Disconnect, change networks, and recover mid-operation; reconcile endpoint state, persistence, and resource counts.
- Before release, record success rate, p50/p95/p99 latency, error classes, and resource high-water marks with explicit rollback thresholds.
Completion is not one passing path. Every terminal state reconciles, automation stays below user intent, and every operational cost has an explicit ceiling.