Real-Time APIs · Real-Time in Practice
Ordering, Gaps and Resynchronization
Detect missed messages and recover state.
Connections drop and messages can be lost or reordered across reconnects and instances. Give each channel a monotonic sequence number; clients track the last seen sequence, detect gaps, and on reconnect request missed messages (since=seq) from a durable store. If the gap is too large, fall back to a full state snapshot plus subsequent deltas. This makes clients self-healing.
Gap handling
| Situation | Recovery |
|---|---|
| Small gap | Fetch missed messages since last seq |
| Large gap / long offline | Snapshot + resume from snapshot seq |
| Duplicate message | Ignore seq ≤ last seen |
| Out-of-order | Buffer briefly, apply in seq order |
Client state: room:42 last_seq = 1830
Receive seq 1833 → gap (1831–1832 missing) → GET /rooms/42/messages?after=1830 → apply 1831, 1832, 1833
Reconnect after 2 h offline → server: gap too large → send snapshot (latest 50 messages + seq 9120) → resume
Common pitfalls
- No sequence numbers (silent data loss).
- Replaying unbounded history after long disconnects.
- Applying duplicates twice.
Key points
- Per-channel sequence numbers
- Gap detection + catch-up
- Snapshots for large gaps
Further reading: HTML spec: Last-Event-ID
Practice questions
How does a client detect missed real-time messages?
Answer
Each message carries a per-channel sequence number; a jump larger than one indicates a gap.
Why fall back to snapshots after long disconnects?
Answer
Replaying thousands of missed deltas is slow and wasteful; a current snapshot plus new deltas restores state quickly.
Open in the app to mark lessons complete, take notes and track your progress.