¿Cuándo usarías WebSockets, SSE o long-polling en vez de HTTP normal?

Question

IT Interview Practice · Accepted Answer

El HTTP normal es **petición/respuesta**: el cliente pregunta, el servidor responde, listo. Eso encaja mal con funcionalidades **en tiempo real** (chat, dashboards en vivo, notificaciones, edición colaborativa) donde el *servidor* necesita empujar datos cada vez que tiene algo nuevo. Las opciones son formas de sortear el modelo iniciado por el cliente de HTTP, a lo largo de un espectro de complejidad:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

El **long-polling** es el recurso de reserva que funciona en todas partes: el cliente hace una petición normal que el servidor mantiene abierta hasta que tiene datos, y luego el cliente vuelve a pedir de inmediato. Aproxima el push sobre HTTP normal pero desperdicia un ciclo de petición por mensaje y añade latencia.

**SSE (Server-Sent Events)** es un stream **unidireccional** (servidor → cliente) ligero y estandarizado sobre una única respuesta HTTP de larga duración. Es ideal cuando solo el servidor empuja — feeds en vivo, notificaciones, progreso, streaming de tokens de LLM. Es simple, corre sobre HTTP/2 normal (sin infraestructura especial) y se reconecta automáticamente. El límite: es unidireccional y solo texto.

Los **WebSockets** promocionan una única conexión HTTP a un canal TCP **full-duplex** persistente donde ambos lados envían en cualquier momento con un overhead mínimo por mensaje. Úsalo para interacción genuinamente bidireccional y de baja latencia: chat, juegos multijugador, editores colaborativos, trading. El coste es operativo: es una conexión con estado para la que hay que configurar proxies, load balancers y autoscalers, y debes construir tú mismo la reconexión, los heartbeats y el backpressure.

**Regla general:** por defecto usa HTTP normal; usa **SSE** para streaming servidor→cliente; recurre a **WebSockets** solo cuando de verdad necesitas tiempo real bidireccional; mantén el **long-polling** como recurso de reserva universal.

## Por qué es importante

Elegir un transporte en tiempo real es una decisión de diseño senior clásica donde la respuesta ingenua ("usa WebSockets para todo") suele ser errónea. Los entrevistadores quieren ver que ajustas la herramienta al *patrón de comunicación* —unidireccional vs bidireccional, necesidades de latencia, volumen de mensajes— y que sopesas el **coste operativo** de las conexiones con estado y de larga duración: sticky sessions, escalado, timeouts de proxy y lógica de reconexión. Reconocer que SSE a menudo cubre "el servidor empuja actualizaciones" de forma más simple que WebSockets, y que el long-polling sigue siendo un recurso de reserva robusto, señala experiencia real en producción en vez de recurrir a la opción más vistosa.

Por qué es importante

Preguntas relacionadas