I'm building a chat application and I need to decide on the best protocol for real-time communication. I've looked at WebSockets and Long Polling, but I'm also hearing about Server-Sent Events (SSE). Since WebSockets keep a connection open, I'm worried about the server memory usage if I have thousands of concurrent users. What's the standard today?
3 answers
For a chat application, WebSockets are the industry standard because they allow for full-duplex, bi-directional communication. Long Polling is very outdated and inefficient because it requires opening a new HTTP request repeatedly. While WebSockets do consume memory per connection, modern servers can handle tens of thousands of concurrent Socket.io or pure WebSocket connections easily. If you only need "one-way" updates (server to client, like a stock ticker), Server-Sent Events (SSE) is actually better because it's lighter and works over standard HTTP without the handshake overhead.
Is it hard to scale WebSockets across multiple server instances using a load balancer?
WebSockets are the way to go for chat. The latency difference compared to polling is night and day for the user experience.
Totally, Karen. Users expect instant messages now. Anything else feels broken in a modern app.
It is slightly more complex than scaling REST, Larry. Since WebSockets are stateful (the client is "stuck" to one server), you need to implement "Sticky Sessions" on your load balancer so the client always goes back to the same instance. Additionally, to broadcast a message to users connected to different servers, you'll need a "Pub/Sub" mechanism, typically using Redis. When a message comes in on Server A, it publishes to Redis, and Server B and C listen to that channel to push the message to their own connected clients.