I read up to 5-6 “problems” and still don’t understand the exact setting they are talking about. All websocket services I have used alleviated tcp issues by som

I read up to 5-6 “problems” and still don’t understand the exact setting they are talking about. All websocket services I have used alleviated tcp issues by some sort of a heartbeat or planned close/reconnect (just like long-polling, which is basically the same thing from tcp perspective). State sync is not a problem if you don’t lose any state on server restarts, which you shouldn’t lose anyway. Moreover, you don’t have to have a conversation over a socket, request can be made over a regular xhr, only realtime events ({type:event, msg:{id, status}}) go back via socket, iff the client is interested in these. If a socket fails, they may reload the page and get this info via xhr again (/api/get-status?id=). The queue is usually natural, the messages are usually realtime. the state on that machine must survive the failure modes of the proxy talking to it. That is, the state must be found. … However, this creates a debt such that a catastrophic socket loss creates a tremendous reconnect pressure. It is terrifying indeed, but boils down to “don’t try to resend the past”, no FUD required. The state of a socket is the same as of an http request: they connect or auth with some id/jwt and then a socket can send events back again. If you can’t hold that reconnect+auth pressure, you likely can’t hold long-poll reconnect+auth pressure, and less likely but still probably you can’t serve clients who refresh their pages aggressively. Put an adaptive rate limiter before your routes already. This is a talk with strange assumptions and without technical details, what is their point beyond selling some Adama? We lived up to the point when people are afraid of streaming in favor of repeated polling?