The question behind the term
A websocket can deliver the next event quickly while a reconnecting client silently misses the previous ten. Realtime correctness requires a durable ordering contract outside the live connection.
A reviewable approach
Commit authoritative state and a recipient-visible sequence atomically. Clients keep a durable cursor, recover the exact interval after reconnect and use stable operation IDs so optimistic retries do not duplicate work.
- Name the source of truth
- Commit change and recovery cursor together
- Make retries idempotent
- Test gaps, duplicates, reordering and resets
The boundary to keep visible
Ordering guarantees must name their scope. A per-user sequence can order account changes without globally ordering every event, and presence remains an ephemeral observation rather than durable proof.
Realtime delivery and durable recovery solve different problems
A live socket reduces delay while it is connected. It cannot prove that a device saw everything during a network gap. A recoverable system commits authoritative changes to durable storage, assigns a cursor within a stated scope, and lets clients request the interval they missed.
Suppose a client has applied sequence 41 and receives 44 after reconnecting. It should fetch 42 and 43, apply them in order, then accept 44. Treating 44 as the new truth loses two changes. The server must retain enough history for the documented recovery window or provide a defined resynchronization path.
Retries need stable identity
A sender can lose its acknowledgement after the server commits a message. Retrying with a new operation ID can create a duplicate. Give the logical send one stable idempotency key and make the server return the recorded result on retry. Reconciliation must also distinguish “queued locally”, “accepted by the server” and “delivered to a recipient”.
Livara Chat documents persistent Socket.IO delivery, a per-user sequence for reconnect recovery and a durable client outbox. This is a scoped product design; it is not a promise that every event in every service has one global order or that presence is durable evidence.
Failure tests worth running
Test a disconnect before commit, after commit but before acknowledgement, between sequential events, and during a device restart. Verify duplicate sends, out-of-order arrival, cursor expiry and account sign-out. A reconnect should recover the exact interval or clearly require a fresh snapshot; a silent gap is the failure to avoid.
References and further reading
Frequently asked questions
Is a WebSocket enough for reliable realtime messaging?
No. A live connection reduces latency. Durable state, stable operation IDs and a gap recovery contract are needed when the connection drops.
What should a client do when it receives sequence 44 after 41?
Fetch and apply the missing 42 and 43 within the documented sequence scope before applying 44, or perform a defined resynchronization if history has expired.