Design Reconnection for Live Screens

Systems & Architecture · real-time, offline, status

Updated 2026-08-04

Pick the transport from what the screen actually needs, because each one produces a different set of states to design:

Polling asks repeatedly and is mostly empty answers, so the delay is bounded and visible.
A one-way stream of server-sent events pushes updates down and needs a reconnect story.
A two-way WebSocket carries input as well and can be open with nothing flowing through it.

Never let an open connection stand in for a working one. A socket can stay open while the service behind it is dead, so the interface needs a heartbeat rather than a connection flag.
Show three states and not two. Live, reconnecting, and disconnected are different situations, and collapsing them into a single dot hides the one the user can act on.
Fetch what was missed on reconnect rather than resuming as if nothing happened. A screen that was disconnected for two minutes is two minutes wrong, and it will not correct itself from the next incremental update.
Mark the gap when a catch-up is not possible. A thin Some updates may be missing. Refresh to be sure. is more honest than a screen that looks continuous.
Space out reconnection attempts and say when the next one is. A silent retry loop and a stalled screen look the same.
Fall back rather than fail. When the socket cannot be established, dropping to periodic fetches keeps the product usable on the networks that block it.
Stop the stream when nobody is looking. A hidden tab holding a live connection open costs battery on one side and capacity on the other.

A live screen is only trustworthy when it admits the moments it is not live.