Why real-time is no longer optional
Five years ago, a dashboard that refreshed every five minutes was acceptable. Today, users expect live data. B2B applications with real-time features see measurably higher engagement and retention than their polling equivalents.
The technical options for building real-time features have matured significantly. Here is a clear breakdown of the three main approaches and when each is appropriate.
Option 1: Polling
How it works: The client asks the server "any updates?" on a regular interval. Every 5 seconds, every 30 seconds, every minute — the client initiates a request and the server responds.
When to use it:
- Data that does not need to be truly live (notifications that can be 30-60 seconds stale)
- Applications with a small number of users where server load is not a concern
- Simple implementations where the development cost of alternatives is not justified
- When the underlying data source does not support real-time queries
The downsides:
- Not actually real-time — always has latency equal to the poll interval
- Server load scales linearly with users and poll frequency
- 90%+ of requests return empty responses (wasted compute and bandwidth)
The implementation: An interval in JavaScript calling your existing REST API. No infrastructure changes. The easiest path, and often the right one for low-frequency updates.
Option 2: Server-Sent Events (SSE)
How it works: The client opens a persistent HTTP connection to the server. The server keeps that connection open and pushes data to the client whenever something changes. The client does not need to ask — the server notifies it.
When to use it:
- Data flows in one direction: server to client (dashboards, notifications, feeds)
- You need lower latency than polling but do not need bidirectional communication
- You want to avoid the overhead of WebSocket infrastructure
The advantages over polling:
- True push: data arrives within milliseconds of the event, not at the next poll interval
- Only one HTTP connection per client, not one per poll interval
- Built into the browser — no special library needed
- Works through most proxies and firewalls (uses standard HTTP)
The limitations:
- One direction only: the client cannot send data back through the SSE connection
- Limited to around 6 concurrent SSE connections per domain in older browsers (not an issue in modern apps with HTTP/2)
The implementation: An SSE endpoint on your server that holds the connection open and writes events. EventSource API in the browser. Simpler than WebSockets, more scalable than polling.
Use cases: Live dashboards, notification feeds, real-time form validation results, AI streaming responses (ChatGPT uses SSE for its streaming output).
Option 3: WebSockets
How it works: A persistent, bidirectional connection between client and server. Either side can send data at any time without the other initiating a request. The connection stays open for the duration of the session.
When to use it:
- Bidirectional communication is required (collaborative editing, chat, multiplayer games)
- Ultra-low latency is critical (trading platforms, real-time auctions)
- High message frequency from client to server (live cursor tracking, real-time collaboration)
The advantages:
- True full-duplex: client and server communicate as equals
- Lowest possible latency (no request/response overhead per message)
- Efficient for high-frequency bidirectional updates
The complexity:
- More infrastructure: WebSocket servers, connection management, message queuing
- State management is more complex (what happens when a connection drops?)
- Harder to scale horizontally (connections are stateful, load balancing is more complex)
- Not HTTP — some proxies and corporate firewalls block WebSocket connections
The implementation options:
- Socket.io: The most common library. Handles reconnection, fallbacks, and room-based broadcasting. Mature but heavy.
- Native WebSockets: Built into the browser, simpler but requires more manual implementation
- Managed services: Ably, Pusher, AWS API Gateway WebSockets — handle infrastructure, you handle logic
Use cases: Chat applications, collaborative document editing, live multiplayer features, real-time trading or bidding systems.
The decision framework
Start by answering: does the client need to send real-time data to the server, or just receive it?
- Receive only + low frequency (notifications, status updates): Polling is fine. Cost of change is low, implementation is trivial.
- Receive only + low latency (live dashboards, streaming responses): SSE. Clean HTTP, easy to implement, scales well.
- Bidirectional (chat, collaborative tools, multiplayer): WebSockets. Worth the complexity.
The most common mistake is reaching for WebSockets when SSE is sufficient. WebSockets are powerful but add meaningful operational complexity. Only use them when you need bidirectional communication.
Infrastructure considerations
Real-time features change your infrastructure requirements:
Connection limits. Each concurrent user holds an open connection. At 10,000 concurrent users, that is 10,000 open connections. This affects your server configuration, load balancer settings, and cloud provider limits.
Horizontal scaling. Stateless HTTP servers scale horizontally trivially. Stateful WebSocket connections do not — a message sent to Server A cannot reach a client connected to Server B without a message broker (Redis pub/sub, Kafka). Plan for this before you need it.
Graceful degradation. What happens when the real-time connection drops? The UI should degrade gracefully to polling, not break. Reconnection logic is not optional — it is the feature.
Message delivery guarantees. Do you need to guarantee every message is delivered? Or is it acceptable to drop messages if the client is briefly disconnected? At-least-once vs at-most-once delivery semantics must be an explicit decision, not an accident.
Real-time features are mature technology. The implementation is well-understood. The operational considerations are where projects go wrong.