Secțiunile articolului
Polling sau webhook? Alege după frecvența evenimentelor, întârzierea acceptată și suportul oferit de ERP.
Un sistem ERP trebuie să știe când apare o comandă nouă, când se modifică un stoc sau când un preț se actualizează. Cum obții această informație? Ai două opțiuni principale: polling și webhook. Dacă alegi greșit, consumi resurse inutil sau primești datele cu întârziere. Iată cum diferă cele două opțiuni.
Definiții rapide
Pentru evenimente rare și predictibile, alege polling-ul. Polling înseamnă că sistemul tău întreabă periodic ERP-ul: „Ai ceva nou?” Întrebarea se repetă la un interval fix (de exemplu, la fiecare 5 minute). ERP-ul răspunde de fiecare dată, chiar dacă nu s-a schimbat nimic. Simplu de implementat, dar risipitor.
Pentru evenimente frecvente sau urgente, webhook-ul reduce întârzierea dacă ERP-ul îl suportă. Webhook înseamnă că ERP-ul însuși te anunță când apare o schimbare. Îi trimiți o adresă (un URL), iar el trimite un mesaj HTTP când are ceva de spus. Eficient, dar cere ca ERP-ul să suporte această funcție și să gestionezi mai atent erorile. Când configurezi un webhook, sistemul tău expune un endpoint HTTP pe care ERP-ul îl cheamă automat la fiecare eveniment, iar tu trebuie să validezi semnătura cererii și să răspunzi cu un cod 200, altfel ERP-ul reîncearcă de câteva ori cu un interval crescător.
Tabel de decizie
| Criteriu | Polling | Webhook |
|---|---|---|
| Complexitate inițială | Scăzută. Un cron job sau un loop simplu. | Medie. Trebuie configurat endpoint-ul, validat cererea, gestionat retry-urile. |
| Eficiență resurse | Scăzută. Trimiți requesturi chiar și când nu s-a întâmplat nimic. | Ridicată. Se consumă resurse doar la eveniment. |
| Întârziere (lag) | Depinde de interval. La 5 minute, întârzierea maximă e de 5 minute. | Depinde de rețea, sistemul sursă și traseul cererii. |
| Fiabilitate | Predictibilă. Dacă requestul pică, următorul va veni la intervalul stabilit. | Fragilă. Dacă notificarea se pierde sau endpoint-ul e down, evenimentul poate fi ratat. Necesită retry și idempotency. |
| Necesită suport ERP | Nu. Orice ERP care expune o API poate fi polled. | Da. ERP-ul trebuie să aibă mecanism de webhook configurat. |
| Potrivire | Evenimente rare și predictibile (ex: actualizare preț o dată pe zi). | Evenimente frecvente sau urgente (ex: comenzi live într-un restaurant). |
Când alegi polling
Dacă evenimentele sunt rare și nu ai nevoie de reacție imediată, polling e suficient. Un exemplu: un magazin care actualizează prețurile o dată pe zi. Poți face polling la fiecare oră sau chiar la fiecare 30 de minute. Întârzierea maximă e de 30 de minute. Dacă este acceptabil depinde de costul întârzierii. Dacă un preț vechi rămâne afișat 30 de minute, pierzi bani? Atunci polling nu e ok.
Polling e și alegerea sigură când ERP-ul nu suportă webhook. În acest caz, polling-ul rămâne singura opțiune. Implementezi un job care rulează la interval, verifică o dată de ultimă modificare sau un flag, și trage ce s-a schimbat. Jobul tău de polling rulează la fiecare 5 minute, trimite un request către API-ul ERP-ului cu un parametru de ultimă modificare, primește un răspuns cu toate înregistrările noi sau modificate, apoi le procesează și actualizează baza locală.
Când alegi webhook
Webhookul e potrivit când timpul contează. Un lanț de restaurante cu comenzi care vin non-stop. O întârziere de 5 minute înseamnă comenzi pierdute sau stocuri incorecte. În acest caz, webhookul este singura opțiune.
Dar adaugă complexitate. ERP-ul trebuie să trimită notificarea. Tu trebuie să ai un endpoint care să o primească. Dacă endpointul e down, ERP-ul va retry de câteva ori. Dacă retry-urile eșuează? Evenimentul e pierdut. Trebuie să implementezi o logică de compensare: poți face și un polling de backup o dată pe oră, ca rezervă. Când endpoint-ul tău cade, ERP-ul încearcă retry-uri cu backoff exponențial de mai multe ori, iar dacă toate eșuează, tu pierzi evenimentul definitiv dacă nu implementezi un polling de backup care să verifice periodic și să recupereze datele.
Regulă simplă de decizie
- Evenimente rare și predictibile → polling.
- Evenimente frecvente și urgente → webhook.
Decide în funcție de frecvența evenimentelor și de întârzierea pe care o accepți.
Ce faci când nu știi?
Poți începe cu polling. E ușor de implementat și de schimbat mai târziu. Măsori câte requesturi trimiți, câte sunt goale. Dacă 90% din requesturi nu aduc nimic nou, treci la webhook. Sau poți combina: polling la un interval larg pentru actualizări lente, webhook pentru cele rapide. Măsori timp de o săptămână câte requesturi goale trimite sistemul tău și câte evenimente reale apar, apoi calculezi procentul de requesturi inutile și decizi dacă trecerea la webhook reduce costurile de bandă și procesare, iar dacă procentul trece de 90%, merită efortul.
Atenție la capcane
Webhookul presupune idempotency. Același eveniment poate fi trimis de două ori. Sistemul tău trebuie să ignore duplicatele. Fără asta, o comandă poate fi procesată de două ori. Zero dubluri e un obiectiv tehnic, nu o garanție. Idempotency înseamnă că sistemul tău stochează un identificator unic al fiecărui eveniment primit, verifică dacă l-a procesat deja și, în caz afirmativ, ignoră duplicatul și răspunde cu un cod de succes pentru a nu forța ERP-ul să reîncerce.
Polling-ul presupune backpressure. Dacă ERP-ul răspunde cu 1000 de comenzi la un singur request, sistemul tău trebuie să le proceseze pe toate înainte de următorul interval. Altfel se acumulează.
Cum iei decizia
Alegerea dintre polling și webhook e o alegere de arhitectură, nu de filozofie. În practică, alege polling-ul când evenimentele sunt rare și webhook-ul când întârzierea este critică, apoi confirmă alegerea cu date. Măsoară frecvența evenimentelor, costul resurselor și toleranța la întârziere timp de o săptămână. Compară requesturile inutile cu evenimentele ratate și păstrează mecanismul care respectă pragurile operaționale ale magazinului.