Real Time Updates medium
TCP has a built-in 'Keep-Alive' mechanism. Why do most real-time apps still implement an application-level Heartbeat (Ping/Pong frames)?
- A TCP Keep-Alive consumes too much bandwidth.
- B App-level heartbeats encrypt the connection.
- C Default TCP Keep-Alive intervals are often too long (e.g., 2 hours), and they don't detect 'Zombie' connections where the intermediate Load Balancer has silently dropped the state.
- D Browsers do not support TCP.
Answer: C. Default TCP Keep-Alive intervals are often too long (e.g., 2 hours), and they don't detect 'Zombie' connections where the intermediate Load Balancer has silently dropped the state.
If a firewall drops a packet silently, the TCP socket might remain 'ESTABLISHED' on the OS for hours. App-level pings (every 30s) allow the application to realize the connection is dead and trigger a reconnect logic immediately.
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?