Skip to main contentSkip to footer
Volver a Recursos

Análisis comparativo de herramientas para comunicación en tiempo real

Se analiza el comportamiento de WebSockets, SSE y Polling para determinar cuál es la herramienta más adecuada en un caso de uso específico.

16 de septiembre de 2025SSE, Backend, Real-time, WebSocket, HTTP

Eres un backend developer y en un sistema para gestionar restaurantes estás implementando un endpoint que se encarga de avisar a los clientes el estado de las ordenes en tiempo real, para resolverlo se te presentan tres herramientas que podrían suplir tu necesidad: Polling, WebSockets y Server-Sent-Events.

Una breve descripción de cada herramienta:

Polling

El Polling no es una "herramienta" como tal, más bien se lo podría considerar una "solución alternativa" al problema de obtener datos en tiempo real cuando no existían herramientas que lo resolvieran. Como sabemos el modelo de request-response tiene un flujo de "abrir conexión -> cliente pide datos -> procesa información -> servidor envía datos -> cerrar conexión" y el polling básicamente consiste en realizar varias peticiones en determinado tiempo.

Ejemplo de polling de 8 segundos:

De este ejemplo podemos sacar tres cosas; lo primero es que es ineficiente ya que en los segundos 2 y 4 consume recursos innecesarios para obtener exactamente la misma respuesta.

En segundo lugar, debido al intervalo de tiempo entre peticiones se perdió un nuevo evento en su momento exacto, y por ultimo agrega latencia considerable, por lo que además de ser impreciso es lento.

WebSockets

Respecto a los WebSockets, este es un protocolo de comunicación que abre una conexión bidireccional donde el cliente y servidor se pueden enviar mensajes en cualquier momento. Por lo que si cambia el estado de un valor el servidor puede decírselo al cliente.

Ahora bien, nosotros no necesitamos comunicación bidireccional. En el caso de un pedido o el progreso de una orden, necesitamos que la comunicación sea en una sola dirección, no en dos: si el servidor tiene un evento se lo hace saber al cliente, pero el cliente no tiene nada que decirle al servidor.

Honestamente hasta hace poco yo era de los que usaba WebSockets para cualquier cosa que necesitara comunicación en tiempo real, pero solo tiene sentido usarlos cuando estamos desarrollando sistemas de mensajería, edición colaborativa, o videojuegos, ya que el cliente y el servidor se comunican en ambas direcciones. Para notificaciones y estado en tiempo real, agrega complejidad que no aporta valor: hay que manejar reconexión, heartbeats, autenticación sobre el protocolo de upgrade, y compatibilidad con proxies y load balancers.

El modelo alternativo

Server-Sent Events (SSE) existe desde 2006 y es parte del estándar HTML5 desde 2014. Es HTTP normal que no cierra la conexión. El servidor puede enviar eventos al cliente en cualquier momento mientras la conexión permanece abierta.

La diferencia no es solo técnica. Es un cambio sobre quién controla el flujo de información: como vimos en el polling, es el cliente quien decide en qué momento recibir información, pero con SSE es el servidor quien le avisa al cliente cuando hay un nuevo evento.

Volviendo al caso inicial, ¿qué herramienta usarías para manejar los pedidos y órdenes en tiempo real? Seguramente ya tienes la respuesta, pero necesitamos datos reales que puedan sustentar esta decisión, por lo que preparé este benchmark en el que realizo exactamente la misma prueba con estas tres herramientas, con 500 clientes concurrentes a lo largo de 4 minutos.

SSE tiene la menor latencia y genera únicamente los requests necesarios — el 79.9% de requests de Polling no contienen datos nuevos. WebSocket genera la misma cantidad de mensajes útiles que SSE, pero con el doble de memoria por conexión y latencia 2× mayor, porque mantiene el canal de lectura activo aunque el cliente nunca envíe nada.

SSE supera al resto de herramientas en este caso específico, pero no porque las otras sean inútiles — tienen un propósito distinto. Los WebSockets son para conexión bidireccional, y de ser posible hay que evitar el polling ya que causa un desperdicio significativo de recursos, a menos de que sea un caso muy específico.

Tabla de decisiones

NecesitasUsa
Servidor notifica al clienteSSE
Cliente y servidor se comunicanWebSocket
No controlas el servidorPolling

Espero te haya gustado y te sea útil este post. Hasta pronto.

Isaías Méndez, Software Developer

Si deseas probar estas tres herramientas por tu cuenta puedes encontrar el código en este repositorio.