Define what real-time means

Before choosing a tool or writing more code, make the requirement concrete. A status page that may update within five seconds needs a different design from a collaborative cursor that should move within a fraction of a second.

Real-time is a product requirement with a latency budget, not the name of one protocol. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

A common failure is to declare “use WebSockets” before measuring direction, frequency, audience, and acceptable delay. The happy path may still work, which makes the mistake easy to miss. write the update direction, latency budget, message rate, audience size, ordering rule, and recovery requirement first. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Choose the least complicated channel that meets the product requirement, and keep a non-live path for recovery. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Write the requirements for incident creation, incident updates, viewer counts, and operator acknowledgements. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.