Cómo elegir la tecnología de tiempo real adecuada

Realtime is not one technology. The right pick depends on data direction, latency needs, scale, and how much complexity you can afford.

The main realtime options are polling/long polling, Server-Sent Events, WebSockets, and WebRTC. Each fits a different shape of problem.

Start with direction: server-to-client only favors SSE, frequent two-way favors WebSockets, and occasional client-to-server is fine over plain HTTP.

On latency: polling lags by its interval, SSE and WebSockets push instantly, and WebRTC is lowest-latency for peer media but the hardest to set up.

Polling is simple and works everywhere, but it wastes requests and adds lag. Reach for it only for low-frequency, non-critical updates.

SSE is a one-way stream over plain HTTP that auto-reconnects and deploys easily — but it can't send client-to-server and hits browser connection caps.

WebSockets give full-duplex, low-latency channels. The cost is a persistent connection plus extra thought for scaling and reconnection.

WebRTC enables direct peer-to-peer audio, video, and data at minimal latency — but with heavy complexity: signaling, NAT traversal, STUN/TURN.

A quick cheat sheet: SSE for one-way notifications, WebSockets for chat and games, WebRTC for video/voice, plain polling for rare updates.

Persistent connections (WebSockets, SSE) reshape scaling: you need sticky sessions or a shared backplane. Polling fits classic stateless servers more easily.

Real systems often go hybrid: REST for commands, WebSockets for live updates, SSE for a status feed. Choosing per-feature beats forcing one tool everywhere.

Recap: match direction and latency to the tool — SSE for one-way, WebSockets for two-way, WebRTC for media, polling for simplicity. Hybrids are common.