Webhooks vs. polling vs. long-polling vs. Server-Sent Events vs. WebSockets — ¿cuándo encaja cada uno?
Cinco respuestas distintas a la misma pregunta —cómo se entera el cliente de que algo cambió— y los entrevistadores la usan para ver si vas directo a WebSockets por costumbre o de verdad pesás las alternativas.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
Webhooks vs. polling vs. long-polling vs. Server-Sent Events vs. WebSockets — ¿cuándo encaja cada uno?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#La misma pregunta, cinco respuestas distintas
"¿Cómo se entera el cliente de que algo cambió en el servidor?" Esta única pregunta tiene cinco respuestas habituales, y los entrevistadores la usan justamente para ver si vas directo a WebSockets por costumbre o si de verdad razonás sobre las restricciones: quién inicia el intercambio, si la conexión queda abierta, y quién se supone que debe ser alcanzable.
#Polling — el cliente sigue preguntando
El cliente dispara una petición a intervalos fijos y revisa si llegó algo nuevo.
Es lo más simple que funciona: request/response plano, sin infraestructura especial, trivial de cachear y limitar por tasa. El costo está metido en el intervalo: la latencia queda acotada por cuán seguido sondeás, y la mayoría de esas peticiones vuelven sin nada nuevo, lo cual es desperdicio puro multiplicado por cada cliente inactivo. Diez mil clientes sondeando cada dos segundos son cinco mil peticiones por segundo sin hacer nada, todo el día, aunque el sistema esté quieto.
#Long polling — el cliente pregunta, el servidor tarda en responder
El cliente manda una petición; en lugar de responder de inmediato, el servidor la mantiene abierta hasta que hay algo que reportar o se cumple un timeout, y ahí responde — el cliente vuelve a abrir una petición nueva de inmediato.
Esto te da entrega casi en tiempo real sin renunciar a la semántica plana de request/response de HTTP/1.1, así que sobrevive a proxies y firewalls viejos que a veces frenan un handshake de WebSocket crudo. El costo se traslada de "peticiones desperdiciadas" a "conexiones mantenidas abiertas": el servidor necesita un modelo de concurrencia (I/O asíncrona, no un hilo por conexión) capaz de sostener miles de peticiones pendientes sin caerse, y hay una pequeña ventana entre que llega una respuesta y se abre la siguiente petición donde un evento podría perderse si no se secuencia con cuidado.
#Server-Sent Events — el servidor sigue hablando
El cliente abre una única conexión HTTP y el servidor le va transmitiendo eventos como text/event-stream, indefinidamente, en una sola dirección.
SSE es HTTP plano por debajo: sin handshake especial, funciona a través de la mayoría de la infraestructura sin configuración, y la API EventSource del navegador maneja la reconexión y la reanudación (vía Last-Event-ID) de forma automática, algo que ni el polling ni el long polling te dan gratis. Su limitación real es la dirección: el cliente no puede mandar datos de vuelta por ese mismo canal, solo abrirlo y escuchar. Sobre HTTP/1.1 los navegadores también limitan las conexiones abiertas por origen (típicamente seis), algo que solía importar en páginas con mucho SSE — HTTP/2 elimina ese techo porque multiplexa streams sobre una sola conexión.
#WebSockets — los dos lados hablan, cuando quieran
Un WebSocket nace como una petición HTTP normal con un header Upgrade: websocket; cuando el servidor responde 101 Switching Protocols, esa misma conexión TCP se convierte en un canal full-duplex y con framing propio, donde cualquiera de los dos lados puede escribir en cualquier momento.
Esta es la única opción de la lista donde el cliente puede enviar datos cuando quiera, no solo recibirlos, y por eso es la opción correcta para chat, edición colaborativa (el tipo de cosa que hacen los editores basados en Yjs), juegos multijugador y interfaces de trading. La factura llega en lo operativo: la lógica de reconexión/backoff y los heartbeats son tu responsabilidad, un WebSocket no tiene el cacheo ni la semántica normal de HTTP, y distribuir mensajes entre varias instancias de servidor necesita un backplane compartido (pub/sub de Redis, un broker de mensajes), porque un mensaje publicado en una instancia no tiene forma de llegar a un cliente conectado a otra instancia sin eso.
#Webhooks — el productor te llama a vos
Las cuatro opciones de arriba ponen al cliente en la posición de mantener una conexión o hacer preguntas. Un webhook da vuelta eso: cuando ocurre un evento, el productor hace una petición HTTP saliente a una URL que el consumidor registró de antemano.
El consumidor no mantiene ninguna conexión abierta mientras está inactivo — costo genuinamente cero hasta que dispara un evento— y por eso esto es lo por defecto en integraciones servidor-a-servidor (Stripe, GitHub y Slack notifican a terceros así). La contrapartida es que el consumidor tiene que exponer un endpoint HTTPS públicamente alcanzable, la entrega es al-menos-una-vez y no exactamente-una-vez (el proveedor va a reintentar ante timeouts o errores, así que el consumidor tiene que deduplicar por ID de evento), el orden no está garantizado entre reintentos, y cualquiera que descubra la URL podría mandar eventos falsos con un POST, a menos que el payload esté firmado (un header de firma HMAC que el consumidor verifica antes de confiar en cualquier cosa del cuerpo).
#Lado a lado
| Modelo | Quién inicia | Conexión | Latencia | Costo en reposo a escala | Encaje típico |
|---|---|---|---|---|---|
| Polling | Cliente | Petición nueva cada ciclo | Acotada por el intervalo | Alto — peticiones constantes de cada cliente inactivo | Cambios poco frecuentes, simplicidad sobre frescura |
| Long polling | Cliente | Abierta hasta datos o timeout | Casi tiempo real | Moderado — muchas conexiones pendientes | Bandejas de notificación, chat pre-WebSocket |
| SSE | Cliente (abre), servidor (empuja) | Una conexión larga, unidireccional | Tiempo real | Moderado — una conexión abierta por cliente | Feeds en vivo, dashboards, notificaciones |
| WebSockets | Cualquiera de los dos | Una conexión larga, full-duplex | Tiempo real | Moderado/alto, según el fan-out | Chat, edición colaborativa, juegos, trading |
| Webhooks | Productor | Ninguna abierta — una petición por evento | Casi tiempo real (depende de la entrega) | Ninguno en reposo | Integraciones servidor-a-servidor, finalización de jobs asíncronos |
#Un marco de decisión, no un default
Empezá por quién es realmente el consumidor. Si es otro servidor y no una pestaña de navegador, un webhook casi siempre le gana a hacer que ese servidor te sondee. Si es un navegador y el cliente solo necesita recibir actualizaciones, SSE te da entrega en tiempo real con reconexión automática y sin el peso operativo de una flota de WebSockets. Andá a buscar WebSockets específicamente cuando el cliente necesita mandar un flujo continuo de datos de vuelta, no solo recibirlo. Y cuando todavía no existe esa infraestructura y los cambios son genuinamente poco frecuentes, el polling es una elección legítima, aburrida y confiable: el error no es usar polling, es sondear cada dos segundos algo que cambia dos veces por día.
🧠 Check your understanding
0/4 · 0/4 answered1. Una integración necesita avisarle al servidor de un partner en el instante en que se completa un pago, y ese servidor no es un navegador. ¿Cuál es la mejor opción?
2. Un dashboard de cotizaciones bursátiles en el navegador solo necesita recibir actualizaciones de precio, nunca mandar datos de vuelta. ¿Cuál es la opción más simple que igual da entrega casi en tiempo real?
3. ¿Por qué un consumidor de webhooks no puede asumir que va a recibir cada evento exactamente una vez?
4. ¿Qué costo operativo es exclusivo de WebSockets entre los cinco modelos discutidos?