Webhook, WebSocket o consulta periódica: cuál usar en cada caso
Publicado el 2026-09-12 por frfrand
Tres formas de enterarse de que algo pasó, con costos muy distintos. Cuatro preguntas que resuelven la decisión sin discutir arquitectura.
Las tres resuelven el mismo problema de fondo: enterarse de que algo pasó. Se diferencian en quién habla primero, cuánto cuesta mantenerlo y qué pasa cuando algo falla.
Las tres, en una línea cada una
Consulta periódica (polling). Preguntás cada tanto. Simple, sin nada que mantener vivo.
Webhook. El otro servicio te llama cuando pasa algo. Sin conexión permanente, pero necesitás una dirección pública.
WebSocket. Una conexión abierta en las dos direcciones. Latencia mínima, a cambio de mantener esa conexión por cada cliente.
Las cuatro preguntas
1. ¿Quién arranca la conversación?
Si el que sabe algo nuevo es un servicio externo (una plataforma de pagos, GitHub, WhatsApp), la respuesta es webhook. No hay discusión: es el mecanismo que esos servicios ofrecen.
Si el que sabe algo nuevo es tu propio backend y el destinatario es un navegador, mirá las otras dos.
2. ¿Con qué frecuencia?
Eventos por hora → webhook o consulta periódica. Eventos por segundo → WebSocket.
Mantener mil conexiones abiertas para avisar de algo que pasa tres veces por día es caro en mantenimiento y en recursos.
3. ¿Hace falta ida y vuelta?
Si el cliente sólo recibe (notificaciones, progreso de una tarea, un panel que se actualiza), Server-Sent Events suele ser mejor que un WebSocket: va sobre HTTP normal y el navegador reconecta solo.
El WebSocket se justifica cuando el cliente también manda seguido: un chat, un editor colaborativo, un juego.
4. ¿Qué pasa si llega tarde?
Si un retraso de treinta segundos no cambia nada, consulta periódica y listo. Es la opción más aburrida y la que menos se rompe.
Por qué la consulta periódica no es la opción perdedora
Tiene mala fama y merece una defensa, porque en producción gana más seguido de lo que se admite:
- No hay conexiones que mantener ni reconexiones que implementar.
- Se recupera sola: si una consulta falla, la siguiente pone todo al día.
- Escala sin pensar: cualquier servidor puede contestar, no hace falta que el cliente vuelva siempre al mismo.
Cuando el volumen es el problema, hay formas intermedias: pedir sólo lo que cambió desde la última vez, o dejar la petición esperando hasta que haya novedades (long polling), que da latencia casi de tiempo real con mucha menos complejidad.
El error clásico
Elegir WebSockets porque suena moderno, y descubrir tres meses después que hay que resolver: reconexión, recuperación de los mensajes perdidos mientras estabas desconectado, sesiones pegajosas en el balanceador, límites de descriptores abiertos, y un Redis para repartir entre servidores.
Todo eso es trabajo real y permanente. Vale la pena cuando el producto lo necesita. No vale la pena para actualizar un contador cada minuto.
Lo más común en la vida real
La mayoría de los sistemas usan dos de las tres, no una sola.
Un ejemplo típico: webhooks para enterarse de lo que pasa afuera (pagos, mensajes, repositorios), WebSocket o SSE para la parte de la interfaz que de verdad tiene que verse en vivo, y consultas periódicas para todo lo demás.
Elegir una sola tecnología para todo es el camino más corto a pelearse con ella.
