Real Time Updates medium
You are building a real-time file transfer tool. Why might you choose WebSockets over Server-Sent Events (SSE)?
- A SSE is not supported by modern browsers.
- B SSE is strictly text-only (UTF-8). Sending binary data requires Base64 encoding (33% overhead), whereas WebSockets support binary frames natively.
- C SSE requires a custom protocol, while WebSockets use HTTP.
- D SSE connections timeout after 1 minute.
Answer: B. SSE is strictly text-only (UTF-8). Sending binary data requires Base64 encoding (33% overhead), whereas WebSockets support binary frames natively.
SSE is designed for text streams. To send an image or file via SSE, you must encode it as text, bloating the size. WebSockets support `ArrayBuffer` and `Blob` types directly for efficient binary transfer.
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?