Real Time Updates hard
A user loses connection for 5 seconds. In a standard WebSocket implementation, the messages sent during that time are lost. How do you implement 'At-Least-Once' delivery for a chat app?
- A Rely on TCP retransmission.
- B Send messages twice.
- C Use a bigger buffer.
- D Implement an 'Ack & Replay' buffer. The server keeps sent messages in a list until the client sends an application-level 'ACK(ID)'. On reconnect, the client sends 'Last-ID=5', and server replays 6+.
Answer: D. Implement an 'Ack & Replay' buffer. The server keeps sent messages in a list until the client sends an application-level 'ACK(ID)'. On reconnect, the client sends 'Last-ID=5', and server replays 6+.
TCP only recovers packets if the connection stays alive. If the socket breaks, the OS discards the buffer. The application must maintain its own history buffer (Event Log) to fill the gaps upon reconnection.
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?