適切なリアルタイム技術の選択

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.