Building Real-Time Features Without the Complexity of WebSockets

Every product manager eventually says "can we make it update in real-time?" And every developer immediately thinks WebSockets — bidirectional, persistent connections, complex state management, connection handling, reconnection logic, and suddenly your simple CRUD app needs a distributed pub/sub system.

Here is the secret: most "real-time" features do not need WebSockets. They need data that updates within a few seconds without the user refreshing. That is a much simpler problem to solve.

The Real-Time Spectrum

Real-time is a spectrum, not a binary:

Seconds-fresh (polling): data updates every 5-30 seconds. Sufficient for: dashboards, notification counts, leaderboards, inventory levels. The simplest approach.

Near-instant (Server-Sent Events): data pushes to the client within 1-2 seconds. Sufficient for: live comments, typing indicators, activity feeds, collaborative presence. Moderate complexity.

Instant (WebSockets): data transmits within milliseconds in both directions. Required for: multiplayer games, live trading, collaborative editing, voice/video. Highest complexity.

Most features that product managers call "real-time" are actually in the seconds-fresh or near-instant category. Match your implementation complexity to your actual requirement.

Option 1: Smart Polling

The simplest "real-time" implementation: fetch data on an interval.

Set up a React Query hook with a refetchInterval of 5 seconds. The data refreshes every 5 seconds without the user doing anything. From the user's perspective, the dashboard "updates itself."

When to use polling:

The data changes infrequently (less than once per minute)

A few seconds of staleness is acceptable

You have few concurrent users viewing the same resource

You want zero additional infrastructure

Optimization: conditional polling. Only poll when the browser tab is active (React Query does this automatically). Stop polling when the user is not looking — resume when they return.

Advanced optimization: long polling. Instead of requesting every 5 seconds and usually getting "nothing changed," the server holds the request open until something changes (or a timeout). This reduces unnecessary requests while providing near-instant updates.

We use polling for our leaderboard page (refreshes every 30 seconds) and notification counts (refreshes every 10 seconds). The implementation is trivial and the user experience is excellent.

Option 2: Server-Sent Events (SSE)

SSE is the middle ground between polling and WebSockets. The server pushes events to the client over a persistent HTTP connection. It is unidirectional (server to client only), uses standard HTTP (works through proxies and CDNs), and reconnects automatically if the connection drops.

How it works: the client opens a connection to an endpoint. The server keeps the connection open and sends data events whenever something changes. The client receives events and updates the UI.

In Next.js, you create an API route that sets the content type to text/event-stream, keeps the response open, and writes events when data changes. The client uses the EventSource API (built into all browsers) to receive events.

When to use SSE:

You need push updates from server to client

The communication is one-directional (server sends, client receives)

You want automatic reconnection and event ID tracking (built into the protocol)

You need it to work through corporate proxies (HTTP-based, unlike WebSockets)

SSE is perfect for: live comment streams, activity feeds, real-time notifications, progress updates for long-running operations, and live collaboration indicators (who is viewing this document).

Option 3: Real-Time Database Subscriptions

Some databases provide real-time subscriptions natively:

Supabase Realtime: subscribe to database changes. When a row is inserted, updated, or deleted, connected clients receive the change immediately. Zero custom backend code for basic real-time CRUD.

Firebase Realtime Database / Firestore: similar concept — subscribe to documents or collections and receive live updates. Battle-tested at massive scale.

Convex: a newer option that makes the entire database reactive. Queries automatically re-execute and push new results when underlying data changes.

When to use database subscriptions: when your real-time needs map directly to database changes. A new comment appears when a row is inserted. A like count updates when a row is modified. No custom event infrastructure needed.

Limitations: database subscriptions struggle with computed or aggregated data. "Show me the real-time count of active users" requires computing across many rows — this is not a simple row change subscription.

Option 4: WebSockets (When You Actually Need Them)

WebSockets are necessary when: communication is bidirectional (both client and server send data), latency must be under 100ms consistently, you need multiplexing (multiple data streams over one connection), or the protocol requires binary data transmission.

Real use cases that require WebSockets: collaborative text editing (every keystroke from every user must propagate instantly), multiplayer games (position updates 30-60 times per second), live trading (millisecond-accurate price updates with order placement), and voice/video calling signaling.

If your feature does not match these characteristics, WebSockets add complexity without benefit.

Implementation Complexity Comparison

Polling: 5 lines of code (set refetchInterval on your query hook). Zero infrastructure changes. Works with any hosting platform including serverless.

SSE: 30-50 lines of code (endpoint + client subscription). Works on most hosting platforms. Some serverless platforms (Vercel) have execution time limits that make long-lived SSE connections impractical — use Railway or Fly.io instead.

Database subscriptions: depends on the database. Supabase Realtime requires one line (subscribe to a channel). But it requires using Supabase as your database.

WebSockets: 200+ lines of code minimum. Requires a persistent server (not serverless). Needs connection management, heartbeat/ping, reconnection logic, authentication, and potentially a message broker (Redis Pub/Sub) for horizontal scaling.

The Scaling Challenge

Polling scales easily: each request is stateless. Your server handles it, responds, and forgets. Load balancers distribute requests normally.

SSE scales moderately: each connected client holds an open HTTP connection. A typical server handles 10,000+ concurrent SSE connections easily. For more, add servers behind a load balancer with sticky sessions.

WebSockets scale with difficulty: each connection is stateful. If user A sends a message and user B is connected to a different server, you need a message broker (Redis Pub/Sub, NATS) to route the message between servers. This adds infrastructure complexity.

Our Approach at AIDToolStack

We use polling for everything currently:

Leaderboard data: refetch every 30 seconds

Notification count: refetch every 10 seconds

Tool ratings: refetch on window focus

This covers our needs because our data does not change often enough to justify push-based updates. A tool's rating might change once per hour. A user might get a notification once per day. Polling every 10-30 seconds provides a good experience without any infrastructure complexity.

When we add features that need faster updates (live collaborative stacks, real-time tool comparison sessions), we will add SSE endpoints. WebSockets are not on our roadmap because we do not have bidirectional real-time requirements.

The Decision Framework

Start with polling. It is trivially simple and handles most cases. Move to SSE when: updates must appear within 1-2 seconds, polling frequency would create unacceptable server load, or you need push notifications without user action.

Move to WebSockets only when: communication must be bidirectional, latency must be under 100ms, or you have multiplayer/collaborative features requiring instant synchronization.

Every level of complexity you add is complexity you must maintain, debug, and operate. Add it when the simpler solution is provably insufficient — not when it seems cool or "proper."