Websockets imply persistent connections between servers and clients. That long-term state tightly couples the two: deploying a change to servers now requires draining all running connections, for example. Load balancing is much harder. Throttling client behavior is much harder, so you’re not as insulated from bad client behavior or heavy hitters. Consequences of that decision ripple through the entire architecture.
I really like the polling approach used here. It’s simple, easy to reason about, and loosely coupled. It will be reliable and resilient.
Saying it might have taken a week to learn websockets completely misses the point. I’ve built large architectures on persistent connections and deeply regretted it.
Exactly! Keeping all of those stateful connections open is a much bigger issue than loadbalancing simple HTTP polls (that you could cache super aggressively). I think this is what this blog post really misses and shows that they have not much of a clue how to operate things at a worldwide scale.
I really like the polling approach used here. It’s simple, easy to reason about, and loosely coupled. It will be reliable and resilient.
Saying it might have taken a week to learn websockets completely misses the point. I’ve built large architectures on persistent connections and deeply regretted it.