A live sports interface does not fail only when the connection goes down.
It can remain online while showing an impossible state: a goal before the score changes, a final whistle while the match is still marked live, or a correction that reaches one screen but not another.
That is why the useful architecture question is not "REST or WebSocket?" It is:
How will the product build, update, verify, and recover its canonical match state?
A production design usually needs both delivery models, plus explicit rules for ordering, idempotency, reconciliation and observability.
