Start with deliberate polling

Start from the behavior you can observe. The board can request an incident snapshot every fifteen seconds and use validators so unchanged responses stay small.

Polling remains a good design when requests are cheap, updates are rare, and a bounded delay is acceptable. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to dismiss polling as primitive and replace one predictable request with a permanent connection immediately. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to implement a measured polling baseline with cancellation, backoff, visibility awareness, and HTTP caching. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Choose the least complicated channel that meets the product requirement, and keep a non-live path for recovery. Record enough evidence that another developer can repeat the result without relying on your memory.

Build the snapshot endpoint and record request count, bytes transferred, and worst-case staleness over two minutes. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.