real-time systems · reliability
When Two Backends Must Speak the Same Real-Time Protocol
What it takes to make a backend fallback operational rather than architectural theater.
Filed under
Ticket Pointing →A second backend is not a fallback because it starts. It is a fallback only when the same browser can cross the boundary without learning that the server changed.
Ticket Pointing keeps the client protocol stable while Go serves as the production primary and Node.js remains available behind health checks. That decision moved compatibility out of documentation and into contract tests: the same room, participant, voting, and facilitator behavior is exercised against both implementations.
The difficult bugs lived at the edges. A browser can reconnect before the previous socket’s disconnect event reaches everyone else. Broadcasting that old disconnect immediately makes a participant disappear after they have already returned. A short grace period lets the new connection cancel the stale broadcast while the database still records the underlying connection state promptly.
The lesson is broader than WebSockets: redundancy creates value only when the boundary is testable and the transition behavior is designed explicitly.