Polling and Long Polling: when WebSocket is overkill

Overview

Polling and Long Polling are techniques for the client to get updated data from the server when the server cannot initiate communication (as WebSocket does). This guide covers complete implementations from database to frontend, including comparison with SSE and WebSocket.

1. Fundamentals

Short Polling

Client makes periodic requests at a fixed interval.

1. Client sends request
2. Server responds immediately (with or without new data)
3. Client waits N seconds
4. Repeats

Simple, but wastes bandwidth with empty responses.

Long Polling

Client makes a request and the server holds the connection until it has data.

1. Client sends request
2. Server holds the connection until it has data or timeout
3. Server responds when there's new data
4. Client immediately makes a new request

Efficient, near real-time without WebSocket.

Why is Long Polling still relevant? WebSocket and SSE are superior, but Long Polling works on any HTTP infrastructure without special configuration. It's the universal fallback — used by Firebase Realtime Database, Slack (as fallback), and CometD.

---

2. Database Layer

PostgreSQL LISTEN/NOTIFY — Trigger for Long Polling

Database Polling — "updated_at" Pattern

Redis Pub/Sub as Long Polling Backbone

---

3. Backend Layer

Short Polling — Express

Long Polling — Complete Express

Long Polling — Python FastAPI

Nginx — Long Polling Configuration

Scaling — Multiple Instances with Redis

---

4. Frontend Layer

Short Polling — React with React Query

Short Polling — Vanilla JavaScript

Long Polling — Complete React Hook

Long Polling — Vanilla JavaScript

---

5. Real-World Use Cases

Chat with Long Polling (Firebase-style)

Deployment Status Polling

Typing Indicator with Short Polling

Mobile — Polling with Battery/Network Awareness

---

6. Pitfalls and Optimizations

Common pitfalls:

• Thundering herd: 10K clients reconnect at the same time after timeout. Solution: add random jitter to reconnect delay
• Proxy timeout: Nginx/ALB close idle connections before long poll responds. proxy_read_timeout must be greater than the long poll timeout
• Memory leak: Waiters not removed when client disconnects. Always clean up on the req.on('close') event
• Stale connections: Client believes it's connected but the connection died. Use periodic heartbeat
• Clock skew: since timestamp can diverge between client and server. Always use serverTime from the response, never Date.now() from the client

---

7. Performance

---

8. Decision Framework

Use Short Polling when:

• Update interval of 5-60s is acceptable
• Implementation needs to be trivial
• Few simultaneous users (< 1K)
• Endpoint already exists (just add refetchInterval on frontend)
• Metrics dashboards, deploy status, notification badges

Use Long Polling when:

• You need near-realtime without WebSocket
• Infrastructure doesn't support WS (firewalls, legacy proxies)
• Fallback for when WebSocket fails
• Simple chat, notifications, basic collaborative editing

Prefer SSE/WebSocket when:

• High volume of events (> 1 event/second)
• Many simultaneous users (> 10K)
• Intensive bidirectional communication (gaming, trading)
• Bandwidth is critical (mobile, low-bandwidth)