La promesa dels webhooks és seductora: un simple endpoint HTTP que rep dades en temps real i desencadena una lògica de negoci sense intervenció humana. Tanmateix, el mateix patró que funciona perfectament en proves unitàries i entorns de desenvolupament es converteix en una font silenciosa de pèrdua de dades quan la producció comença a respirar. El fall és previsible: rebre un esdeveniment i processar-lo en el mateix flux síncron. Aquesta arquitectura, tot i que intuïtiva, no escala, no tolera fallades i acaba devorant informació crítica en els pics de trànsit.
Imaginem un escenari real: una botiga en línia que integra comandes mitjançant un webhook de Shopify. El handler rep el payload, crida un model de llenguatge per classificar el producte, sincronitza amb un CRM i envia una confirmació per WhatsApp. Tot funciona en local. Però en producció, amb cent comandes simultànies, la crida a la IA es dispara de 400 ms a 4 segons. El proveïdor del webhook, que espera una resposta 200 en menys de 3 segons, interpreta el silenci com una fallada i reintenta el mateix esdeveniment. Si el reintent coincideix amb un altre pic, el webhook s'abandona. La comanda es perd sense deixar rastre en logs ni excepcions. És un forat negre de dades.
La solució és conceptualment senzilla però exigeix disciplina d'implementació: separar la recepció del processament. L'endpoint ha de fer dues coses i només dues: emmagatzemar l'esdeveniment brut en un repositori durador i retornar un 200 immediatament. Tot el treball pesat —crides a API externes, transformacions, enviaments— es posa en cua i s'executa de manera asíncrona. Aquest patró, conegut com 'ingest-and-acknowledge', elimina d'arrel la categoria de fall per timeout de webhook.
Portar aquesta idea a la pràctica amb n8n i Node.js requereix un petit esforç d'enginyeria que paga la pena. n8n, per defecte, executa el flux complet de forma síncrona quan rep un webhook. És ideal per prototipat, però per volums reals cal afegir una capa lleugera d'ingesta. Podem construir un endpoint mínim en Node.js (Express o Fastify) que rep el payload, genera una clau d'idempotència (per exemple, un hash del cos i la font), persisteix l'esdeveniment en Postgres o Redis amb estat 'pendent', respon 200 i encua una tasca en una cua com BullMQ. n8n, llavors, no es dispara directament des del webhook, sinó que actua com a consumidor d'aquesta cua. D'aquesta manera, n8n continua orquestrant la lògica de negoci, però la recepció és ultralleugera i desacoblada.
La idempotència és el primer gran avantatge. Cada esdeveniment rep un identificador únic determinista. Abans d'inserir, verifiquem si aquest ID ja existeix al magatzem d'esdeveniments bruts. Si el proveïdor reintenta el webhook, el magatzem rebutja el duplicat i retornem 200 sense processar de nou. Sense aquesta protecció, un reintent pot generar una comanda duplicada, un càrrec doble o una confirmació enviada dues vegades. Els grans proveïdors de webhooks envien duplicats eventualment; la idempotència a l'entrada és una assegurança contra això.
El segon avantatge és la tolerància a fallades sense pèrdua de dades. Si la crida al model de llenguatge falla o el CRM retorna un error, l'esdeveniment original segueix segur al magatzem. El consumidor de la cua pot reintentar amb polítiques de backoff exponencial, i si després de diversos intents persisteix la fallada, la tasca es mou a una cua de missatges morts (dead-letter queue). Allà roman com un registre consultable i depurable, no com una dada que simplement es desvaneix. Configurar removeOnFail: false a BullMQ marca la diferència entre una fallada invisible i una fallada gestionable.
El tercer benefici és l'escalat independent. L'endpoint de webhook només escriu una fila i respon 200. Això pot gestionar milers de peticions per segon sense suar. El processament pesat —que inclou crides a models d'IA, integracions amb CRMs, enviament de notificacions— escala en el seu propi grup de consumidors, amb un límit de concurrència controlat. Així, un pic de 500 comandes no satura l'API d'OpenAI ni el límit de taxa del CRM; només allarga la cua temporalment. Cap esdeveniment es perd.
La temptació d'afegir rate limiting a l'endpoint de webhook és comprensible però errònia. Les limitacions de taxa s'han d'aplicar al consumidor, no a la ingesta. L'endpoint ha d'acceptar sempre i emmagatzemar. El consumidor, amb un paràmetre de concurrència (per exemple, 5 processos simultanis), respecta els límits de les API externes sense bloquejar l'entrada. Si la cua creix, el sistema s'alenteix però no falla.
A Q2BSTUDIO, hem aplicat aquest patró en múltiples projectes per a clients que depenen de fluxos de negoci crítics activats per webhooks. Des de la integració de passarel·les de pagament fins a l'orquestració d'agents d'IA que processen leads en temps real, la separació entre recepció i processament és un pilar arquitectònic. La nostra experiència ens ha ensenyat que la fiabilitat no s'improvisa: es construeix amb decisions de disseny primerenques, com l'elecció d'un magatzem d'esdeveniments durador, la configuració acurada de les polítiques de reintent i el monitoratge constant de les cues de missatges morts.
Per a equips que estan començant a escalar, recomanem un enfocament progressiu. Primer, implementar la capa d'ingesta amb Node.js i una cua simple com Bull. Després, connectar n8n com a consumidor, externalitzant la lògica de negoci. Més endavant, afegir mètriques de latència de cua, alertes sobre tasques fallides i un panell d'administració per reprocessar esdeveniments. Aquest camí permet créixer sense reescriure el sistema.
Si la teva arquitectura actual processa webhooks de forma síncrona i comences a notar timeouts esporàdics, comandes perdudes o duplicades, el patró d'ingest-and-acknowledge és la primera auditoria que has de realitzar. Es pot implementar en mig dia i prevé una classe d'errors que només apareixen en el pitjor —o millor— moment: el pic de trànsit. La inversió és mínima comparada amb el cost d'una dada perduda.
A Q2BSTUDIO oferim serveis d'automatització de processos que inclouen el disseny d'arquitectures de webhook resilients, integració de fluxos d'IA i desplegament en cloud AWS o Azure. També desenvolupem solucions d'intel·ligència artificial que requereixen processament asíncron d'esdeveniments, com agents conversacionals o classificadors en temps real. El nostre equip combina experiència en Node.js, n8n, cues de missatges i cloud computing per construir sistemes que no només suportin la càrrega, sinó que la converteixin en un avantatge competitiu.
