Dlaczego Twój e-commerce traci na zbyt długich webhookach? 3 ciche zabójcze opóźnienia

Webhooki – niby proste, a jak potrafią napsuć krwi. W e-commerce często są traktowane po macoszemu: „działa, więc po co ruszać”. Problem w tym, że działają, ale robią to wolno, a w handlu online każda sekunda opóźnienia to realne straty. Klient odświeża stronę, a stan magazynowy nadal pokazuje dostępność towaru, który już został kupiony. Zamówienie przechodzi, a potem dostajesz zwrot z powodu braku towaru. Albo płatność wisząca w limbo przez minutę, bo webhook nie przebił się na czas. Brzmi znajomo? To typowe objawy zbyt długich webhooków.

W tym artykule pokażę trzy konkretne scenariusze, w których opóźnione webhooki rujnują biznes, i podpowiem, jak je wyeliminować. Nie będzie teorii – tylko praktyka z frontu.

Pierwszy zabójca: opóźniona aktualizacja stanu magazynowego

Wyobraź sobie popularny model butów w sklepie internetowym. Klient A dodaje go do koszyka, ale jeszcze nie płaci. Klient B też go ogląda. W momencie, gdy A finalizuje zakup, webhook powinien zaktualizować stan magazynowy w czasie rzeczywistym. Ale jeśli webhook opóźnia się o 2–3 sekundy, B widzi towar dostępny i też go kupuje. Wynik? Podwójne zamówienie na jeden produkt.

W praktyce wygląda to tak: system zarządzania zamówieniami (OMS) wysyła webhook do systemu magazynowego (ERP). Jeśli integracja nie jest zoptymalizowana – na przykład ERP jest obciążony, a webhook nie ma mechanizmu kolejkowania priorytetów – opóźnienie narasta. Klient B składa zamówienie, dostaje potwierdzenie, a potem info o braku towaru. Zaufanie leci, koszty obsługi zwrotu rosną.

Jak to naprawić? Użyj kolejek, które nadają priorytet webhookom związanym z magazynem. Ustaw timeout na 500 ms i jeśli nie zdążysz – przepuść request przez backup endpoint. W JurskiTech wdrożyliśmy u klienta system buforowania, gdzie webhooki krytyczne (jak update stanu) leciały do dedykowanego serwisu, a nie do ogólnego API. Opóźnienie spadło z 3s do 400 ms.

Drugi zabójca: blokujące webhooki w procesie płatności

Kolejny klasyk: bramka płatności wysyła webhook, a ty go przetwarzasz w głównym wątku aplikacji. Jeśli webhook jest zbyt uniwersalny – na przykład aktualizuje status zamówienia, wysyła email, loguje zdarzenie – wszystko w jednym bloku synchronicznym – to każdy etap czeka na poprzedni. Bramka płatności ma swoje timeouty, więc jeśli nie odpowiedziesz w ciągu 10 sekund, uzna transakcję za nieudaną i wyśle ponownie. Tymczasem klient siedzi na stronie z komunikatem „oczekiwanie na płatność” i denerwuje się.

Przykład z życia: sklep odzieżowy używał popularnej platformy płatności. Webhook przychodził i odpalał sekwencyjnie: zapis w bazie → wysyłka maila do klienta → wysyłka maila do logistyki → aktualizacja panelu admina. Jeśli któryś z tych kroków zawodził (np. serwer SMTP nie odpowiadał), całość się wieszała. Klient dostawał błąd, choć płatność przeszła. A ponowne webhooki z bramki generowały nadmiarowe zapytania.

Rozwiązanie? Asynchroniczność. Odbierz webhook, zwróć 200 OK, a resztę przerób w tle. Użyj kolejki (np. RabbitMQ) lub zwykłego kolejkowania w Redisie. W JurskiTech często zalecamy rozdzielenie logiki: webhook tylko zapisuje zdarzenie, a osobny worker obsługuje wysyłki maili i logistykę. Działa szybko i niezawodnie.

Trzeci zabójca: zbyt wiele webhooków w jednym żądaniu

Problem dotyczy głównie sklepów z dużą liczbą integracji: system ERP, CRM, narzędzia marketingowe, aplikacje do logistyki. Każda zmiana statusu zamówienia generuje osobny webhook do każdego systemu. Jeśli zrobisz to synchronicznie, czekasz na odpowiedź każdego z nich. Jeden zewnętrzny API może być wolny, a reszta musi czekać. To jak autostrada z jednym pasem.

Byłem u klienta, który miał 5 integracji: shop ERP, księgowość, magazyn zewnętrzny, platformę marketingową i chatbota. Każde zamówienie generowało 5 webhooków, które leciały jeden po drugim. Całość trwała nawet 15 sekund. Klient tracił zamówienia, bo bramka płatności timeoutowała.

Tu sprawdza się model event-driven. Zamiast wysyłać osobne zapytania do każdego systemu, wygeneruj jeden event wewnętrzny (np. „order.placed”), a poszczególne serwisy niech go subskrybują. Dzięki temu nie blokujesz głównego procesu, a każda integracja działa niezależnie. W skali setek zamówień dziennie różnica jest kolosalna.

Jak realnie skrócić czas webhooków?

Poza konkretnymi rozwiązaniami opisanymi wyżej, warto wprowadzić kilka ogólnych zasad.

Po pierwsze: monitoruj czasy webhooków. Większość narzędzi (np. Sentry, Datadog) pozwala śledzić opóźnienia endpointów. Ustaw alarmy – jeśli webhook trwa dłużej niż 1 sekunda, coś jest nie tak.

Po drugie: testuj pod obciążeniem. W JurskiTech często spotykamy się z klientami, którzy wrzucają webhooki na produkcję bez żadnych testów wydajnościowych. A potem podczas Black Friday system pada. Zrób symulację 100 równoczesnych webhooków i zobacz, jak reaguje.

Po trzecie: stosuj deduplikację. Bramki płatności często wysyłają te same webhooki wielokrotnie. Jeśli nie masz mechanizmu odrzucania duplikatów (np. unikalne ID), możesz dwukrotnie zaktualizować stan magazynowy i zrobić bałagan. Prosty Redis z TTL to często za mało – warto użyć mechanizmu idempotentności.

Podsumowanie

Zbyt długie webhooki w e-commerce to cichy zabójca konwersji. Opóźnienia w aktualizacji stanu magazynowego, blokujące procesy płatności i przeciążenie integracyjne – to trzy najczęstsze grzechy. Na szczęście każdy z nich da się wyeliminować: przez asynchroniczność, kolejki priorytetowe i event-driven architekturę.

W JurskiTech na co dzień pomagamy firmom wycisnąć maksimum wydajności z ich integracji. Jeśli czujesz, że Twoje webhooki działają ospale, a klienci narzekają na opóźnienia – czas spojrzeć pod maskę. Bo w e-commerce czas to pieniądz i to dosłownie.