Webhooks: por qué tu sistema se entera tarde de las cosas

El panel de ventas de una tienda con web y local físico muestra los números de hace veinte minutos. No es una avería ni un error de programación: es que, cada cierto tiempo, ese panel llama —usando la misma vía que ya se explicó al hablar de qué es una API— al sistema de ventas y le pregunta «¿hay algo nuevo?». Si la pregunta llega justo después de una venta, esa venta tarda hasta la siguiente ronda de preguntas en aparecer en pantalla. Nadie ha roto nada. El sistema simplemente está diseñado para preguntar, no para escuchar.

Es el mismo síntoma, con nombres distintos, en casi cualquier negocio que junta varios sistemas: el informe de reservas que llega con retraso, el aviso de un pedido nuevo que tarda en aparecer en la pantalla del almacén, el contador de aforo de un recinto que va por detrás de lo que está pasando de verdad en la puerta. En todos los casos, antes de pensar que algo está averiado, merece la pena preguntar una cosa: ¿este sistema pregunta, o le avisan?

#La causa: preguntar en vez de que te avisen

Imagina que esperas un paquete importante y, en vez de confiar en que el mensajero te llame al llegar, decides llamarle tú cada diez minutos para preguntar «¿ya estás aquí?». La mayoría de esas llamadas van a ser inútiles —el paquete sigue en camino, nada ha cambiado— y aun así vas a tener que hacerlas todas, porque no tienes otra forma de saberlo. Y encima, aunque llames sin parar, en el peor caso vas a enterarte de que ha llegado casi diez minutos después de que lo haga, porque llamaste justo antes.

Eso es, en software, «preguntar cada cierto tiempo» —lo que en el sector se suele llamar sondear o consultar en bucle—. Un sistema le pregunta a otro, una y otra vez, a intervalos fijos, si hay algo nuevo. Funciona, pero es caro y lento a la vez, y las dos cosas por el mismo motivo: caro porque la inmensa mayoría de esas preguntas no traen nada nuevo y aun así consumen recursos en hacerlas, y lento porque, aunque preguntes cada minuto, lo que pasó justo después de la última pregunta no se sabrá hasta la siguiente.

#Qué es un webhook, en una frase

Un webhook es lo contrario: en vez de que tú preguntes, el otro sistema te avisa en el momento en que pasa algo. Es el mensajero llamándote al llegar, no tú llamándole a él cada diez minutos. Le dices de antemano «cuando pase esto, avísame en esta dirección», y desde ese momento no tienes que preguntar nada más: el aviso llega solo, en cuanto ocurre lo que estabas esperando, y no antes ni mucho después.

Por eso un panel conectado por webhook se actualiza al segundo de producirse una venta, y uno que solo sabe preguntar se queda, en el mejor de los casos, con el retraso del intervalo que se haya configurado entre pregunta y pregunta.

La palabra en sí no ayuda nada a entenderlo —«webhook» no significa nada por su cuenta en español, es un nombre técnico que se quedó tal cual—, así que lo único que merece la pena recordar es la idea de fondo: es una dirección tuya, un buzón, que le das al otro sistema para que deje ahí el aviso en el momento justo en que ocurre lo que te interesa. Tú no vigilas el buzón a cada minuto. El buzón te avisa cuando llega algo.

#El problema del que nadie te avisa

Aquí está la trampa que casi nadie ve venir: si el aviso se pierde por el camino —un fallo de red, un servidor caído justo en ese segundo, una respuesta que nunca llega—, nadie se entera de que se ha perdido. El sistema que envía el aviso puede dar por hecho que llegó. El que debía recibirlo simplemente no sabe que existía. No hay una alarma que salte sola diciendo «faltó un aviso»: el silencio es indistinguible de que no ha pasado nada.

Por eso ningún sistema serio puede depender solo de los avisos para tener los datos completos. Hace falta un plan B: una forma de comprobar, de vez en cuando —una vez al día, por ejemplo—, que lo que se recibió por avisos coincide con lo que de verdad ocurrió, y de recuperar lo que se haya podido perder por el camino. Preguntar de tarde en tarde, como red de seguridad, convive perfectamente con usar webhooks. Es, de hecho, la comprobación que hace razonable confiar en ellos.

Piensa en un restaurante con dos locales que usa los avisos automáticos para llevar cada venta a su contabilidad al instante. Si un aviso se pierde y nadie tiene una comprobación de respaldo, ese ingreso simplemente desaparece de la contabilidad sin que nadie lo note, hasta que alguien cuadra caja a fin de mes y el número no encaja. La comprobación diaria de respaldo es lo que evita que un fallo de un segundo, en una conexión de internet, se convierta en un agujero contable que tarda semanas en descubrirse.

#Por qué recibir el mismo aviso dos veces es normal

Hay otra cosa que sorprende la primera vez que se ve: en ocasiones llega el mismo aviso repetido, exactamente igual, dos veces seguidas. Nadie ha cometido ningún error, ni el proveedor ni quien montó la integración: así funciona el aviso por red. Si el sistema que envía el aviso no recibe confirmación rápida de que ha llegado bien, por precaución vuelve a enviarlo, por si el primero se perdió. A veces el primero sí llegó, y lo que se pierde es solo la confirmación, no el aviso. El resultado es el mismo dato, dos veces.

Un sistema bien construido tiene que dar por hecho que esto va a pasar y estar preparado para no duplicar nada por ello —no crear dos pedidos, no cobrar dos veces, no enviar dos correos por la misma venta—. Esa capacidad de recibir lo mismo repetido y no duplicar el resultado tiene nombre propio y se explica con detalle en el artículo sobre idempotencia: merece su propia explicación porque es, de largo, la parte que más quebraderos de cabeza da si nadie la tiene en cuenta desde el principio.

#Reintentos, registro y recuperación: las tres respuestas que exigir

Antes de dar por buena una integración basada en webhooks, conviene hacer tres preguntas concretas a quien te la ofrece, porque las respuestas dicen si el sistema está pensado para fallar bien o va a fallar mal el día que algo se pierda:

• ¿Qué pasa si el aviso no llega? Un proveedor serio tiene una respuesta clara: cuántas veces reintenta, durante cuánto tiempo, y qué pasa si después de todos los intentos sigue sin llegar.
• ¿Hay un registro de los avisos enviados? Si algo falla y quieres saber qué pasó, necesitas poder consultar un historial, no confiar en la memoria de nadie.
• ¿Cómo se recupera lo que se perdió? Debe existir alguna forma —automática o manual— de pedir de nuevo lo que no llegó, sin tener que reconstruirlo a mano desde cero.

Un sistema que responde bien a estas tres preguntas te está diciendo, en el fondo, que ha pensado en el día en que algo falle. Y algo, tarde o temprano, siempre falla.