Which use case is best served by SSE?

Which use case is best served by SSE?

• A. When the server needs to push real-time updates to clients but the client does not need to respond with high-frequency messages.
• B. For high-frequency bidirectional chat.
• C. For video conferencing.
• D. For static content caching.

Answer: (A)

Server-Sent Events are designed for a simple, unidirectional channel from server to client over HTTP, where the client keeps a long-lived connection and the server streams events as they occur. This pattern is ideal when you need real-time updates pushed from the server to clients, and the client doesn’t need to send back frequent messages. That matches a scenario where the server pushes new data or notifications to listeners without requiring a high-frequency reply path from each client. It wouldn’t fit well for high-frequency bidirectional chat, which needs two-way, low-latency communication (a WebSocket-like solution would be more appropriate). It also isn’t suitable for video conferencing, which relies on real-time audio/video streams rather than server-sent text events (requiring technologies like WebRTC). And for static content caching, there’s no need for a streaming channel at all—the goal there is efficient delivery and caching of assets, not live event streaming.

Server-Sent Events are designed for a simple, unidirectional channel from server to client over HTTP, where the client keeps a long-lived connection and the server streams events as they occur. This pattern is ideal when you need real-time updates pushed from the server to clients, and the client doesn’t need to send back frequent messages. That matches a scenario where the server pushes new data or notifications to listeners without requiring a high-frequency reply path from each client. It wouldn’t fit well for high-frequency bidirectional chat, which needs two-way, low-latency communication (a WebSocket-like solution would be more appropriate). It also isn’t suitable for video conferencing, which relies on real-time audio/video streams rather than server-sent text events (requiring technologies like WebRTC). And for static content caching, there’s no need for a streaming channel at all—the goal there is efficient delivery and caching of assets, not live event streaming.