Push vs Pull: WebSockets vs SSE vs Long Polling

1. Core idea

• Polling → client repeatedly asks server for updates.
• Push → server sends updates when available.
• WebSockets → persistent, bidirectional connection.
• SSE → persistent, server-to-client event stream.
• Long polling → client request stays open until update or timeout.

Analogy: Polling = checking mailbox repeatedly. Long polling = asking postman to wait. SSE = one-way live broadcast. WebSocket = two-way phone call.

2. Compare protocols

Short polling

Client calls GET /updates every N seconds.

• Pros: Simple, stateless requests, easy HTTP caching where applicable.
• Cons: Repeated requests, update delay, wasted traffic.
• Use: Infrequent updates; simplest implementation.

Long polling

Server holds request until update or timeout; client reconnects.

• Pros: Near-real-time updates without persistent bidirectional protocol.
• Cons: Reconnect overhead, open requests, timeout and proxy handling.
• Use: Legacy systems or environments where SSE/WebSockets aren't suitable.

SSE (Server-Sent Events)

One persistent HTTP connection → server streams events to client.

• Pros: Simple HTTP, automatic browser reconnect support, event IDs.
• Cons: One-way only; connection limits can matter with HTTP/1.1.
• Use: Notifications, live status, progress updates.

WebSockets

Persistent, bidirectional connection → either side sends messages anytime.

• Pros: Low-latency two-way communication, efficient for frequent messages.
• Cons: Connection lifecycle, heartbeats, routing, backpressure, and reconnect logic.
• Use: Chat, multiplayer games, collaborative editing, interactive live dashboards.

3. Decision rule

• Server → client only → SSE.
• Client ↔ server, frequent real-time messages → WebSockets.
• Updates every few seconds/minutes → short polling.
• Near-real-time needed but architecture constrained → long polling.

Choose SSE for live export progress; cost is maintaining open connections. Switch to WebSockets when client must send frequent interactive messages over same connection.

4. AWS mapping

API Gateway

• WebSocket APIs support bidirectional messaging.
• HTTP APIs support ordinary HTTP request/response; SSE can be implemented through suitable HTTP streaming architecture, but verify integration/runtime limits.
• Managed connection routing, but connection count, message rate, timeouts, and pricing matter.

Application Load Balancer (ALB)

• Supports WebSocket upgrades and can proxy suitable HTTP streaming connections.
• Configure idle timeouts appropriately; deployments and target failures can disconnect clients.

Amazon ECS / EKS

• Run SSE or WebSocket servers.
• Need connection draining, graceful shutdown, reconnect handling, and capacity planning.

AWS Lambda

• Suitable for polling endpoints and event-driven backend work.
• Lambda execution is not a general-purpose forever-running connection handler; use a supported gateway/streaming architecture for persistent client connections.

5. Scale example

Assume 100,000 connected clients.

Short polling every 5 seconds:

100,000/5=20,000 req/sec100,000/5 = 20,000 req/sec 100,000/5=20,000 req/sec

Even with no updates, server receives 20K req/sec.

SSE or WebSockets: Approximately 100K concurrent connections, but request rate can be far lower when events are infrequent. Each connection still consumes resources; every broadcast may create huge fan-out.

If one event is sent to all 100K clients → 100K outbound messages. At 1 KB/message → roughly 100 MB of payload per broadcast, before protocol overhead.

6. Failure modes

• Disconnects: Reconnect with exponential backoff + jitter.
• Missed events: SSE Last-Event-ID can support resumption if server retains and replays events.
• Slow clients: Bound queues; drop/coalesce stale updates or disconnect slow consumers.
• Server deploy: Gracefully drain connections; clients reconnect.
• Many connections: Monitor active connections, memory, send latency, disconnect rate, and per-client queue size.
• WebSocket auth: Authenticate at connection establishment; revalidate long-lived sessions and authorize individual actions.

7. Interview questions

Q1. Why not use WebSockets for everything?

More connection and lifecycle complexity than needed for one-way or infrequent updates.

Q2. SSE vs WebSockets?

SSE is server-to-client over HTTP; WebSockets are bidirectional.

Q3. Is SSE reliable by itself?

No. Reconnect helps, but replay needs event IDs and server-side retention.

Q4. Why can polling overload servers?

Request frequency multiplies by client count, even when no data changes.

Q5. How scale WebSockets horizontally?

Load balancing + connection-aware routing where needed, shared pub/sub or event distribution, reconnect strategy, and explicit fan-out planning. Sticky sessions alone don't distribute broadcasts.

Q6. Which for Scheduled Exports at Project44?

SSE for one-way progress/status updates. WebSockets only if users need frequent two-way interaction. Polling is simpler if updates are infrequent.

8. One-line interview answer

“I’d choose based on directionality and update frequency: polling for simple infrequent checks, SSE for one-way live updates, and WebSockets for frequent bidirectional communication; then plan reconnects, backpressure, fan-out, and connection capacity.”