Webhooks vs. Polling: Por Qué tu Web Debería Dejar de Preguntar "¿Ya Llegamos?"
El problema de las preguntas constantes
Cuando construimos una aplicación web moderna, rara vez funciona de forma aislada. Necesita hablar con otros sistemas: una pasarela de pagos para saber si una tarjeta fue aprobada, un servicio de envíos para saber si un paquete se entregó, o un CRM para registrar un nuevo cliente.
El gran desafío de la arquitectura de software es cómo hacemos que esos sistemas se comuniquen de forma eficiente. Históricamente, el debate se reduce a dos enfoques: Polling y Webhooks.
Para entender la diferencia, imaginemos un viaje largo en auto.
El Polling agota los recursos haciendo preguntas repetitivas, mientras que un Webhook simplemente avisa cuando hay novedades.
Polling: El Síndrome del "¿Ya Llegamos?"
El Polling (o sondeo) es el método tradicional. Funciona haciendo que tu sistema le pregunte repetidamente al otro sistema si hay alguna novedad.
Volviendo a la analogía del auto, el Polling es como un niño sentado en el asiento de atrás preguntando cada cinco minutos: "¿Ya llegamos? ¿Ya llegamos?".
En código, esto significa que tu servidor le envía una petición a la pasarela de pagos cada 10 segundos preguntando: "¿El usuario ya pagó?". La gran mayoría de las veces, la respuesta de la pasarela será negativa.
El problema: Suele ser ineficiente. Estás gastando recursos del servidor y ancho de banda en hacer preguntas que casi siempre reciben un "no" por respuesta. Si tenés miles de usuarios haciendo esto, la infraestructura se satura. (Aunque a veces se usa Long Polling o sondeo con Backoff exponencial para mitigarlo, sigue teniendo un costo).
Webhooks: "No nos llames, nosotros te llamamos"
Los Webhooks son una alternativa eficiente basada en eventos. En lugar de preguntar constantemente, tu sistema le da al otro sistema una dirección (una URL) y le dice: "Avisame acá cuando pase algo importante".
En el viaje en auto, usar un Webhook es como encender el GPS y relajarse. No necesitás preguntar nada; sabés que la voz te va a interrumpir automáticamente justo en el momento en que llegues al destino.
En la práctica, cuando un usuario hace una compra, tu servidor espera. Cuando el pago se aprueba, la pasarela toma la iniciativa y envía un mensaje (una petición HTTP, usualmente POST) a la URL de tu Webhook.
// Ejemplo conceptual de cómo recibir un Webhook
app.post('/webhook-pagos', (req, res) => {
// 1. Validar seguridad (ej. firma HMAC)
if (verificarFirma(req)) {
procesarPagoAprobado(req.body);
res.status(200).send('Recibido');
}
});
Consideraciones clave: Aunque los Webhooks ahorran muchísimos recursos, requieren implementar validaciones de seguridad (como firmas HMAC para asegurar que el mensaje viene realmente de la pasarela), manejo de reintentos e idempotencia (para no procesar un pago dos veces si la pasarela envía el aviso por duplicado).
