Real Time Updates hard
Socket.IO uses a multi-step handshake (Long Polling -> Upgrade to WebSocket). Why does this architecture force you to use 'Sticky Sessions' (Session Affinity) at the Load Balancer?
- A It keeps the TCP connection alive longer.
- B WebSockets are stateful.
- C The HTTP Long Polling request creates a session ID in server memory. The subsequent Upgrade request must hit the *same* server to find that ID, or the handshake fails.
- D It reduces latency.
Answer: C. The HTTP Long Polling request creates a session ID in server memory. The subsequent Upgrade request must hit the *same* server to find that ID, or the handshake fails.
Standard WebSockets can be load balanced statelessly if the handshake happens in one go. Socket.IO's fallback mechanism splits the handshake into multiple HTTP requests, requiring them to land on the same node to share the `sid` context.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- When a mobile app is closed/backgrounded, it cannot keep a WebSocket open. How does it receive real-time alerts (like 'New Message')?
- For a human user, what is generally considered the maximum acceptable latency for an interaction to feel 'Real-Time' (e.g., typing in a Google Doc)?
- If you want to update a news feed on a website every time a new article is published, what is the simplest (but least efficient) 'Real-Time' technique?
- In a persistent real-time connection, what is the purpose of a 'Heartbeat' or 'Ping/Pong' message?
- Why is Short Polling considered 'Chatty'?
- Server-Sent Events (SSE) are ideal for which type of real-time application?