Każdy, kto kiedykolwiek prowadził sklep e-commerce przez Black Friday, zna to uczucie. Godzina zero. Promocja startuje. Tysiące użytkowników uderza jednocześnie w serwer. I w najlepszym wypadku sklep zwalnia do granic możliwości, w najgorszym pada całkowicie.
Ale "pada" to zbyt łagodne słowo. Zobaczmy co tak naprawdę dzieje się w środku.
Anatomia awarii sklepu e-commerce
Typowa awaria podczas skokowego ruchu nie wygląda jak nagłe wyłączenie światła. Wygląda jak powolna śmierć.
Pierwsze symptomy pojawiają się subtelnie. Czas odpowiedzi serwera rośnie z 200ms do 800ms. Użytkownicy zaczynają odświeżać strony bo "coś się nie ładuje". Każde odświeżenie to nowe żądanie do serwera. Serwer dostaje coraz więcej requestów, spowalnia jeszcze bardziej, użytkownicy odświeżają jeszcze częściej. To błędne koło które kończy się zawsze tak samo.
Baza danych zaczyna kolejkować zapytania. Connection pool się wyczerpuje. PHP-FPM albo Node nie może obsłużyć kolejnych żądań i zaczyna je odrzucać. Nginx zwraca 502 lub 503. Klienci widzą białą stronę z błędem.
W tym momencie tracisz nie tylko sprzedaż z tej godziny. Tracisz zaufanie klientów którzy właśnie próbowali coś kupić i dostali błąd. Tracisz budżet reklamowy który generował ten ruch. Tracisz pozycje SEO bo Google widzi niedostępną stronę. I tracisz czas który musisz poświęcić na gaszenie pożaru zamiast świętować sukces kampanii.
Koszt godziny przestoju dużego sklepu e-commerce to dziesiątki tysięcy złotych. Koszt przestoju w Black Friday to często wielokrotność miesięcznych przychodów.
To nie jest problem który rozwiązujesz lepszym hostingiem. Możesz dokupić trzy razy więcej zasobów i nadal mieć ten sam problem jeśli ruch jest wystarczająco skokowy. Auto-scaling w chmurze pomaga, ale ma latency rzędu minut, a Twój serwer pada w sekundy.
To jest fundamentalny problem architektury: nieograniczona liczba użytkowników kontra skończone zasoby systemu.
Stare rozwiązanie, nowe zastosowanie
Rozwiązanie jest stare jak kolejki w sklepach spożywczych. Zamiast pozwolić wszystkim wejść naraz, wpuszczasz po X osób na raz, a reszta czeka w kolejce z informacją o swoim miejscu i szacowanym czasie oczekiwania.
W świecie fizycznym to oczywiste. Ikea nie pozwala wejść nieograniczonej liczbie klientów jednocześnie. Kolejki przed sklepami w Black Friday to nie błąd systemu, to świadoma kontrola przepływu.
W e-commerce ten sam mechanizm nazywa się virtual waiting room i stosują go największe platformy sprzedażowe na świecie przy premierach produktów, dropach i flash salach.
Właśnie to budujemy jako DropReady.
Kto to już robi i dlaczego tego nie kupiliśmy
Rynek wirtualnych poczekalni istnieje. Są na nim gracze którzy robią to od lat.
Queue-it to prawdopodobnie najlepiej znany produkt w tej kategorii. Obsługuje premiery Nike, Ticketmaster, rządowe strony podczas rejestracji szczepień. Solidny produkt, sprawdzony w boju przy milionach użytkowników. Cena? Od kilku tysięcy dolarów miesięcznie wzwyż, zależnie od ruchu. Dla enterprise to rozsądna inwestycja. Dla małego lub średniego sklepu e-commerce to nieakceptowalny koszt.
Waiting Room by Cloudflare to opcja dostępna w planach Enterprise Cloudflare. Eleganckie rozwiązanie jeśli i tak używasz Cloudflare na tym poziomie. Jeśli nie, kolejna bariera wejścia.
Fastly ma podobną funkcjonalność w swoim CDN. Znowu, enterprise pricing, enterprise complexity.
Wspólny mianownik wszystkich tych rozwiązań: są zaprojektowane dla firm które obsługują miliony użytkowników i mają działy IT które mogą to wdrożyć i utrzymać. Dla sklepu PrestaShop który raz w roku robi Black Friday, żadne z tych rozwiązań nie ma sensu ekonomicznego ani operacyjnego.
Poza tym wszystkie powyższe rozwiązania opierają się na architekturze WebSocket, która wymaga utrzymywania stałego, otwartego połączenia przez cały czas oczekiwania użytkownika. Przy setkach tysięcy czekających oznacza to gigantyczny, stanowy klaster serwerów. I jest krucha: zerwane połączenie mobilne (jazda pociągiem, wyjście z zasięgu) to użytkownik który wypada z kolejki.
Więc zamiast płacić za coś przewymiarowanego i architektonicznie kruchego, postanowiliśmy zbudować to sami. A skoro już budujemy, budujemy to jako produkt który możemy sprzedawać innym sklepom które mają ten sam problem.
Czym jest DropReady
DropReady to wirtualna poczekalnia dla sklepów e-commerce. Gdy ruch na stronie przekracza zdefiniowany próg, nowi użytkownicy trafiają do kolejki zamiast bezpośrednio na stronę. Widzą swoje miejsce w kolejce, szacowany czas oczekiwania i są automatycznie wpuszczani gdy zwolni się slot.
Sklep działa stabilnie. Użytkownicy wiedzą że czekają, a nie że strona jest zepsuta. Serwer nie pada.
Dlaczego to budujemy teraz
Mamy własny projekt, dealit.gg, marketplace dla influencerów który wkrótce startuje. Przewidujemy że launch wygeneruje skokowy ruch w krótkim czasie i potrzebujemy dokładnie tego rozwiązania.
To jest klasyczny "eat your own dog food" moment. Zamiast kupować gotowe narzędzie, budujemy własne. A skoro już budujemy, to budujemy to jako produkt który możemy sprzedawać innym.
Stack technologiczny i architektura
Backend: Go i KeyDB. Zamiast obciążać system kruchymi połączeniami WebSocket, postawiliśmy na potężny silnik in-memory i Adaptive Polling z Jitterem. Go w połączeniu z fasthttp radzi sobie z dziesiątkami tysięcy zapytań na sekundę przy minimalnym zużyciu RAM, całkowicie bezstanowo.
Co to oznacza w praktyce? Użytkownik na niestabilnym połączeniu mobilnym nie wypada z kolejki. Serwer nie utrzymuje tysięcy otwartych deskryptorów plików. Cały system skaluje się poziomo bez żadnej stanowej synchronizacji między nodami.
Integracja: Early Intercept. Nie używamy wklejanego na stronę kodu JS, który pozwala serwerowi przyjąć cios zanim zadziała. Przechwytujemy ruch na samym brzegu infrastruktury klienta (3 linijki w PHP, Node lub Nginx), weryfikujemy kryptograficzne bilety Ed25519 offline i odciążamy bazę danych w 100%. Serwer klienta nigdy nie widzi żądania od użytkownika który jeszcze czeka w kolejce.
Co planujemy zbudować w MVP
Minimalny zakres który pozwoli przetestować produkt na dealit.gg:
Kolejka z Adaptive Polling, pozycją i estimated wait time
Dashboard admin (włącz/wyłącz, limit jednoczesnych użytkowników)
Early Intercept integration dla PHP i Nginx
Podstawowe statystyki (peak concurrent users, average wait time)
Nic więcej. Billing, multi-tenant, panel klienta — to wszystko po tym jak produkt przeżyje pierwszy prawdziwy ruch.
Co dalej
Kolejne wpisy z tej serii będą techniczne. Dlaczego Adaptive Polling bije WebSockety przy tym przypadku użycia, jak wygląda weryfikacja tokenów Ed25519 w PHP i jak testujemy system przy symulowanym obciążeniu przed launchem dealit.gg.
Jeśli prowadzisz sklep e-commerce i problem skokowego ruchu jest Ci znajomy, zapisz się na early access przez formularz na stronie DropReady.
FAQ
Czym jest virtual waiting room i jak działa?
Virtual waiting room to system który kontroluje przepływ użytkowników do strony lub aplikacji. Gdy ruch przekracza zdefiniowany próg, nowi użytkownicy trafiają do kolejki zamiast bezpośrednio na serwer. Widzą swoje miejsce w kolejce i szacowany czas oczekiwania, a są automatycznie wpuszczani gdy zwolni się slot.
Czym Adaptive Polling różni się od WebSocket w kontekście wirtualnej kolejki?
WebSocket wymaga utrzymywania stałego, otwartego połączenia przez cały czas oczekiwania użytkownika, co przy setkach tysięcy czekających oznacza gigantyczny, stanowy klaster serwerów i jest kruche na niestabilnych połączeniach mobilnych. Adaptive Polling z Jitterem pozwala serwerowi obsługiwać zapytania bezstanowo i natychmiast zwalniać zasoby, co czyni system odpornym na zerwania połączeń i łatwym do skalowania poziomego.
Co to jest Early Intercept i dlaczego to lepsze niż snippet JS?
Snippet JS wklejony na stronę pozwala serwerowi klienta wygenerować HTML zanim kolejka zadziała, czyli serwer i tak przyjmuje cios. Early Intercept przechwytuje ruch na samym brzegu infrastruktury klienta (3 linijki w PHP, Node lub Nginx) i weryfikuje kryptograficzne bilety Ed25519 offline. Serwer klienta nigdy nie widzi żądania od użytkownika który jeszcze czeka w kolejce.
Dla jakich sklepów i platform jest przeznaczony DropReady?
DropReady jest przeznaczony dla sklepów e-commerce każdej wielkości które doświadczają skokowego ruchu podczas flash sale, premier produktów lub kampanii sezonowych jak Black Friday. Integracja działa z każdą platformą, PrestaShop, Bagisto, WooCommerce lub własnym rozwiązaniem na Laravel, przez 3 linijki kodu po stronie backendu.