La fiecare proiect de integrare nou intalnesc aceeasi intrebare: conectam sistemele prin webhook direct sau punem un event bus la mijloc? Raspunsul scurt nu exista. Raspunsul lung tine de volum, tolerante la eroare si cati bani esti dispus sa pui pe infrastructura. Dupa zeci de integrari construite pe n8n pentru clienti din Romania, am un filtru simplu de decizie. Il impart aici cu capcanele pe care le-am vazut.
Ce face webhook direct
Sistemul A genereaza un eveniment (plata confirmata, comanda noua, lead creat). Trimite un POST catre un endpoint al sistemului B. B proceseaza, raspunde 200. Gata. Fluxul e liniar, cuplat strans, simplu de debugat cand merge si neiertator cand nu merge.
Pe proiectul de automatizare facturare Stripe -> SmartBill asa am lucrat. Stripe trimite webhook la n8n, n8n cheama API SmartBill, factura se emite. 30 de minute de setup per client, zero infrastructura in plus. Pentru 20-300 de plati pe luna, varianta asta e clar castigatoare.
Ce face event bus
Sistemul A publica un eveniment intr-un broker (Redis Streams, RabbitMQ, Kafka, AWS SNS/SQS, chiar o tabela Postgres cu LISTEN/NOTIFY). Oricate sisteme vor sa reactioneze la evenimentul ala se aboneaza separat. A nu stie cine il consuma, nu-i pasa daca B e picat, evenimentul ramane in coada pana il ia cineva.
Cuplarea e slaba, retry-ul vine gratis, mai poti adauga consumatori noi fara sa modifici producatorul. Platesti in schimb complexitate de operare: un proces in plus de monitorizat, scheme de evenimente de versionat, un manual pentru cand coada creste fara capat.
Trade-off-ul real, nu cel din articolele cu tabele frumoase
Cifrele care conteaza cand alegi intre cele doua:
- Latenta capat-la-capat. Webhook direct: sub o secunda pe flux sanatos. Event bus: 1-5 secunde in configuratii rezonabile, mai mult daca ai consumatori lenti.
- Tolerant la pici-uri. Webhook direct pica odata cu sistemul downstream. Event bus absoarbe varfuri, sistemul downstream le digera in ritm propriu.
- Retry si dead-letter. Webhook direct: le construiesti singur in n8n sau pierzi evenimente la prima eroare tranzitorie. Event bus: le ai deja in protocol.
- Fan-out. Webhook direct scaleaza prost cand vrei ca acelasi eveniment sa ajunga la 3-4 sisteme. Ajungi sa duplici apeluri HTTP din producator. Event bus e exact pentru asta.
- Complexitate operationala. Webhook direct: un flux n8n, un log. Event bus: broker, cozi, consumer groups, metrici, alerte separate.
Niciunul dintre punctele astea nu conteaza in abstract. Toate conteaza in contextul cifrei tale de evenimente pe zi.
Regula practica pe care o aplic
Decid in trei intrebari:
1. Cate sisteme reactioneaza la acelasi eveniment?
Unul singur: webhook direct. Trei sau mai multe: event bus. La doua, depinde de urmatoarele doua intrebari.
2. Cate evenimente pe zi, la varf?
Sub 500/zi: webhook direct. n8n cu retry configurat face treaba. Peste 5.000/zi sau cu varfuri imprevizibile: event bus. Intre, intra in discutie cat de critice sunt si ce SLA vrei.
3. Ce se intampla daca pierzi un eveniment?
Nimic grav (notificare de marketing, sync de cosmetica): webhook direct. Bani sau reputatie (facturare, stoc, plati): trebuie dead-letter queue garantat, deci event bus sau webhook direct cu persistenta pe disc si retry robust.
Capcana 1: race conditions la sincronizare bidirectionala
Pe webhook direct, daca sistemul A si sistemul B pot modifica aceeasi entitate in aceeasi secunda, una o suprascrie pe cealalta in tacere. Am vazut asta pe un flux CRM – ERP unde lead-urile ajungeau cu date inconsistente. Pana am observat, trecuse o saptamana.
Solutia practica pe webhook direct: last-write-wins cu timestamp si un log de modificari la care sa pot reveni. Merita 2-3 ore in plus la implementare ca sa eviti o dupa-amiaza de debugging intr-o vineri. Pe event bus, ordonarea per cheie (partition key in Kafka, FIFO in SQS) rezolva problema mai curat, cu costul ca pierzi din paralelism.
Capcana 2: polling disfasizat ca webhook
Cateva API-uri spun „avem webhook” dar livreaza evenimente batch o data la minut. Termenul e inselator, ce livreaza de fapt e polling la intervale. Daca ai nevoie de reactii in secunde (notificare WhatsApp la comanda noua, de exemplu), intrebi explicit inainte: latenta tipica, garantii de ordine, ce se intampla la downtime. Un studiu pe 30 de milioane de cereri de polling arata ca 98,5% sunt inutile si consuma de 66 de ori mai multe resurse decat webhooks reale. Verifica asta inainte de orice promisiune catre client.
Capcana 3: fan-out prin copy-paste in producator
Apare tipic in integrari Shopify sau GoMag: prima integrare webhook direct merge, apoi clientul vrea „si pe MyCalls si pe SmartBill si pe un Google Sheet”. Dezvoltatorul adauga endpoint-uri noi la producator pana cand un endpoint incet blocheaza tot lantul. Momentul ala e semnalul ca vrei un event bus. Daca ramai pe webhook direct, macar muti fan-out-ul intr-un nod n8n dedicat care imparte evenimentul si are retry izolat per destinatie.
Caz concret: cand am ramas pe webhook direct, cand am migrat
Pentru integrarea completa post-comanda Shopify (WhatsApp, facturare, apeluri, curierat) am ramas pe webhook direct. Volumul: 150-300 comenzi pe zi. Patru sisteme downstream, dar fluxurile sunt independente si n8n gestioneaza retry per nod. Event bus ar fi adaugat o zi de setup si o componenta in plus de monitorizat fara beneficiu real la volumul ala. Implementare finala: 3-4 zile, 100% comenzi facturate automat.
Am migrat catre event bus (Redis Streams, in cazul respectiv) cand un client de e-commerce a urcat la 12.000 comenzi pe zi in campanie si webhook-urile direct incepeau sa genereze timeout-uri in lant cand API-ul de curierat avea 2 secunde de latenta in plus. Broker-ul a absorbit varfurile, consumatorii au procesat in ritm propriu, zero comenzi pierdute.
Unde se plaseaza n8n in discutia asta
n8n ramane orchestrator, nu broker. Il folosim ca pe un strat de logica intre producator si consumatori: validare, mapare, transformari. Pentru volume mici si medii, n8n plus webhook direct acopera 80% din cazurile clientilor nostri. Pentru volume mari, n8n citeste din broker (consumator de Redis Streams sau SQS) si face orchestrarea la fel, doar ca input-ul vine din coada, nu direct din API-ul producatorului.
Rezultatul in practica: aceeasi platforma acopera ambele regimuri, doar arhitectura din fata se schimba.
Ce monitorizam efectiv, dupa go-live
Indiferent ce alegi, instrumentarea face diferenta intre flux sanatos si flux picat tacut. Pe webhook direct monitorizam rata de erori 4xx/5xx per endpoint, latenta p95 si numarul de retry-uri pe ora. Alerta se triggereaza cand rata de erori trece 1% pe interval de 15 minute sau cand vedem acelasi eveniment ratand retry-ul de trei ori. Pe event bus urmarim in plus adancimea cozii (cat de mult creste si in ce ritm), lag-ul per consumer group si mesajele ajunse in dead-letter queue. Un lag care creste liniar timp de 10 minute e semn ca un consumator pica sau ca producatorul a intrat in varf neanticipat. Fara indicatorii astia, descoperi problemele cand te suna clientul, nu cand sunt inca mici.
Ce retin, concret
Webhook direct cand: un consumator, sub 500 evenimente/zi, pierderi ocazionale tolerabile, vrei sa livrezi in ziua 1. Event bus cand: trei sau mai multi consumatori, varfuri imprevizibile, garantii strice de livrare, sau te pregatesti sa scalezi la 5.000+ evenimente pe zi. Intre cele doua nu exista o linie clara, exista un calcul facut onest pe cifrele tale. Daca cifrele lipsesc, incepi cu webhook direct si migrezi cand dovezile o cer, nu cand o diagrama spune ca „e best practice”.
Daca ai un flux concret pe care il evaluezi (volum real, sisteme implicate, tolerante), putem sa ne uitam impreuna si sa iti spunem onest daca e cazul sau nu. Ia legatura.
