Dashboards en tiempo real: WebSockets, SSE y arquitectura edge

“Tiempo real” es una palabra que se usa con elasticidad. Para un trader de alta frecuencia significa microsegundos; para un dashboard de operaciones de empresa puede ser segundos. La elección de la arquitectura depende de qué nivel de “tiempo real” hace falta —y cómo se factura el resultado a la cuenta de hosting.

Este post recorre las opciones técnicas, sus diferencias reales y cuándo conviene cada una.

Por qué importa la diferencia

Construir un dashboard que se actualiza tiene tres formas principales de hacerlo:

1. Polling: el cliente pregunta cada N segundos.
2. Server-Sent Events (SSE): el servidor empuja al cliente, una sola dirección.
3. WebSockets: comunicación bidireccional persistente.

Cada una tiene un perfil distinto de complejidad, costo y compatibilidad.

Polling: el más simple

El cliente hace una request HTTP cada N segundos al endpoint que devuelve el estado actual. JavaScript con setInterval(fetch, 5000).

Ventajas

• Trivial de implementar.
• Compatible con cualquier infraestructura HTTP: balanceadores, CDNs, proxys, todo lo entiende sin configuración especial.
• Stateless en el servidor.

Desventajas

• Ineficiente: cada request lleva headers HTTP completos, autenticación, cookies. Si el dato cambia poco, la mayoría son requests vacías.
• Latencia: con polling cada 5 s, en el peor caso el dato llega 5 s tarde.
• Carga server-side: con muchos clientes, multiplicas la carga linealmente.

Cuándo conviene

• Datos que cambian lentamente (cada minuto o más).
• Cantidad de clientes chica (decenas).
• No se justifica complejidad extra.

Variante: long polling

El cliente abre la request y el servidor no responde hasta que tiene algo que decir (o hasta un timeout). Reduce el “ruido” de polls vacíos pero introduce su propia complejidad.

Server-Sent Events (SSE)

Estándar definido en WHATWG HTML Spec. Wikipedia y MDN lo describen como una técnica donde “el servidor puede enviar nuevos datos a una página web en cualquier momento, empujando mensajes a la página”.

Una conexión HTTP se mantiene abierta. El servidor escribe eventos en formato text/event-stream. El cliente los recibe en un EventSource.

const source = new EventSource('/api/stream');
source.onmessage = (event) => {
  const data = JSON.parse(event.data);
  updateDashboard(data);
};

Ventajas

• Sobre HTTP estándar: pasa sin cambios por proxys, CDNs, balanceadores HTTP.
• Reconnect automático: si se cae la conexión, el cliente reintenta.
• Last-Event-ID: posibilidad de retomar desde el último mensaje recibido.
• Bajo overhead: una sola conexión persistente.
• Simple de implementar server-side.

Desventajas

• Solo unidireccional (server → client).
• Conexiones simultáneas por dominio limitadas en algunos navegadores (típicamente 6 sobre HTTP/1.1; mucho mayor sobre HTTP/2).
• Soporte en Internet Explorer no existe (irrelevante en 2026, mencionado por completitud).

Cuándo conviene

• Dashboards donde solo el servidor empuja datos.
• Notificaciones, feeds de actualización.
• Métricas en vivo donde el cliente no necesita responder.

WebSockets

Estándar RFC 6455 (IETF, diciembre 2011) según Wikipedia. Protocolo separado del HTTP que provee comunicación full-duplex sobre una sola conexión TCP.

Wikipedia lo describe como “una conexión que permite interacción full-duplex entre un browser (o aplicación cliente) y un servidor con menor overhead que alternativas half-duplex como HTTP polling” (fuente). El handshake usa HTTP estándar (ports 80/443), después se hace upgrade al protocolo WebSocket.

const ws = new WebSocket('wss://api.example.com/dashboard');
ws.onmessage = (event) => updateDashboard(JSON.parse(event.data));
ws.send(JSON.stringify({ type: 'subscribe', channel: 'metrics' }));

Ventajas

• Bidireccional: cliente y servidor pueden emitir.
• Bajo overhead por mensaje (frames pequeños, no headers HTTP completos).
• Latencia muy baja (orden de RTT de la red).
• Ideal para casos donde el cliente necesita enviar comandos además de recibir.

Desventajas

• Más complejo server-side: necesitás runtime que maneje conexiones persistentes (Node.js, Go, Python con FastAPI/aiohttp, Elixir).
• Stateful: cada conexión es estado en algún servidor; complica balanceo y deployment.
• Algunos proxies / firewalls corporativos tienen problemas con WebSockets si no se configuran bien.
• Reconexión y reintento son responsabilidad del desarrollador (no automático como SSE).

Cuándo conviene

• Chat, colaboración en vivo (cursores, edición concurrente).
• Trading, aplicaciones sensibles a latencia.
• Dashboards donde el cliente interactúa (filtros, comandos al servidor).
• Juegos online en tiempo real.

Tabla comparativa

Criterio	Polling	SSE	WebSocket
Dirección	Cliente pide	Servidor empuja	Bidireccional
Protocolo	HTTP	HTTP (long-lived)	WebSocket (TCP)
Reconnect automático	N/A (request única)	Sí	No (manual)
Overhead por update	Alto (headers full)	Bajo	Muy bajo
Latencia mínima	Intervalo de poll	Casi inmediata	Casi inmediata
Compatibilidad infra	Total	Alta	Media (proxies cuidado)
Complejidad server	Mínima	Baja	Media-Alta
Stateful	No	Sí (mientras dura)	Sí
Casos típicos	Estado lento, simple	Feeds, notificaciones	Colaboración, comandos

Edge computing en dashboards

Edge computing es ejecutar lógica cerca del usuario, en regiones distribuidas. Plataformas: Cloudflare Workers, Vercel Edge Functions, Deno Deploy, AWS Lambda@Edge.

Cuándo aporta

1. Reducción de latencia

Si tu dashboard sirve usuarios globales, ejecutar la lógica en un nodo edge cercano al usuario reduce el RTT en cientos de milisegundos. Crítico para WebSockets/SSE donde la primera conexión define la experiencia.

2. Cache inteligente cerca del usuario

Estados que cambian poco se pueden cachear en edge con invalidación selectiva. Ejemplo: configuración del dashboard, lista de canales suscriptos, datos de sesión.

3. Filtrado y agregación

En lugar de que el cliente reciba miles de eventos y filtre localmente, edge puede filtrar por sesión y mandar solo lo que cada cliente necesita. Reduce ancho de banda y CPU del cliente.

4. Geo-routing

Suscriptores en Argentina hablan con un edge en São Paulo o Buenos Aires; suscriptores en Europa hablan con uno en Madrid. Cada uno tiene latencia local, no una latencia global hacia un único origin.

Limitaciones del edge

• Estado distribuido es difícil: si hay datos compartidos entre clientes en distintos edges, hace falta capa de sincronización (Cloudflare Durable Objects, Redis distribuido, similares).
• Cold starts (en algunos providers): la primera conexión puede ser lenta si el edge llevaba inactivo.
• Costo por uso: a alto volumen, edge puede ser más caro que un servidor dedicado bien dimensionado.

Decisiones por tipo de dashboard

Dashboard interno (10-50 usuarios concurrentes)

• Datos cambian cada 5-30 segundos.
• Polling cada 10-15 s + spinner suave es perfecto.
• Cero complejidad agregada.
• Hosted donde sea, sin edge.

Dashboard de operaciones (50-500 usuarios)

• Datos cambian segundo a segundo.
• SSE encaja: servidor empuja métricas, cliente solo escucha.
• Stack: backend con SSE endpoint (Node, Go, Python con SSE soportado), frontend con EventSource.

Dashboard colaborativo (500+ usuarios o multi-usuario)

• Cliente envía eventos también (filtros, anotaciones).
• WebSockets es el camino.
• Probablemente conviene edge para distribución global y/o Durable Objects para estado compartido.

Status pages públicas (millones de visitantes)

• Datos cambian rara vez.
• HTML estático regenerado cada 30-60 segundos vía ISR (Incremental Static Regeneration) o build hooks.
• Cero conexiones persistentes; CDN sirve todo.

Errores comunes

”Hagamos WebSockets de entrada porque suena profesional”

Si el caso de uso no requiere bidireccional ni latencia ultra-baja, agregás complejidad de stateful, reconexión y debugging sin beneficio. Empezar con polling y migrar cuando se justifique.

”Polling cada segundo”

Polling agresivo (1 segundo) con muchos clientes es la receta para saturar el backend. Si necesitás eso, ya pasaste el umbral de SSE/WebSockets.

”WebSocket sin reconexión”

WebSocket sin lógica de reconnect es frágil. Cualquier blip de red corta la conexión y el dashboard queda con datos viejos sin que el usuario se entere. Implementar exponential backoff con jitter y mostrar estado de conexión al usuario.

”Stateful en edge sin Durable Objects o equivalente”

Si tu Edge Function asume que el cliente vuelve al mismo edge, te equivocaste. Edge es por definición distribuido y stateless por defecto. Estado compartido requiere capa explícita.

Conclusión

Tiempo real en dashboards no es un concepto monolítico: es un espectro de opciones. Polling es la opción simple y subestimada para muchos casos. SSE es subestimado por buenas razones y debería ser la elección por defecto cuando solo el servidor empuja. WebSockets es la herramienta correcta cuando hay interactividad real. Edge computing complementa cuando hay distribución geográfica o necesidad de baja latencia global.

La elección correcta empieza por preguntarse: ¿qué tan en tiempo real, para cuántos usuarios, con qué presupuesto operativo?. La respuesta a eso decide la arquitectura, no las preferencias de stack.

Fuentes y referencias

• Wikipedia — WebSocket
• WHATWG HTML — Server-Sent Events
• MDN — WebSockets API
• MDN — Server-sent events

Fuentes

• Wikipedia — WebSocket (RFC 6455)
• WHATWG HTML Standard — Server-Sent Events
• MDN — WebSockets API
• MDN — Server-sent events