SSE, Websocket, Socket.io And Redis

More notes on SSE - https://whoop.ankitwww.com/board/sd-general-client-communication

General idea for scaling SSE with Redis:

• Use Redis Streams as a central event log for all topics.
• Each SSE server instance reads from Redis Streams and pushes events to its connected clients.
• Give each event a unique Redis Stream ID and send it in the SSE id: field.
• When clients reconnect, they send Last-Event-ID, and any instance can replay missed events from Redis.
• This makes servers stateless for event history, so you can add/remove instances freely without sticky sessions.

In other words:

You store each event in Redis under its topic (usually one stream per topic), and when a client connects to any SSE server:

1. They include Last-Event-ID (and the topic they want).
2. The server reads from that ID onward in Redis for that topic.
3. The server streams all missed events first, then stays subscribed for new ones.

That way:

• No sticky sessions needed.
• Any server can handle any reconnect.
• Missed events are reliably replayed.

Formation notes - https://drive.google.com/file/d/1nHHX6wFLovt0dq9NEvtLFoij35o7mvF6/view?usp=sharing

Socket.io

It’s built on top of WebSockets but is more than just WebSockets — it adds:

• Automatic fallback to other transports (like long polling) if WebSockets aren’t supported.
• Event-based API (send custom events instead of just raw text/binary).
• Automatic reconnection if a connection drops.
• Room and namespace support for grouping clients.