Define what real-time means

“Make it real-time” is not a spec. A status board that may lag five seconds behind the server needs a different design from a shared cursor that should feel instant.

Real-time is a latency budget, not the name of one protocol. Write the numbers down before you pick SSE, WebSockets, or plain polling.

What to write down

For our incident board, I start with six fields:

direction: server -> browser (viewers), browser -> server (operators)
latency budget: incident visible within 3 seconds
message rate: about 2 updates per minute normally, bursts to 20
audience: up to 500 viewers, 5 operators
ordering: newer incident state wins; never roll back
recovery: after disconnect, board must match a fresh snapshot

That table turns a vague request into something you can test. If the product owner says “instant,” ask what instant means in seconds. If they cannot answer, pick a number and write it in the doc.

Direction matters first

Incident updates flow from server to many browsers. Operator acknowledgements flow the other way. Draw the arrows before you read any tutorial.

Server ----incident.updated----> Viewer browsers
Viewer browsers --ack command--> Server

One-way fan-out points at SSE. Frequent two-way chatter points at WebSockets. Infrequent updates with a delay you can tolerate point at polling. The free WebSocket vs SSE vs polling helper walks through the same trade-off if you want a second opinion.

Make recovery explicit

The happy path hides bad assumptions. A green “connected” badge does not mean the client has the latest incident list.

Write what happens after a tab sleeps, a proxy drops the stream, or the server restarts. Our board keeps a snapshot route and replays or refetches when the live channel gaps.

Try this on your own project: fill in the six fields for one feature, then pick the simplest channel that meets every line. Change one number on purpose, predict what breaks, and check whether you were right.