Gildia.pl: architektura, koszty i proces stojące za każdą udaną przedsprzedażą

Dla większości sklepów internetowych Black Friday to jedyny moment w roku, na który trzeba się szczególnie przygotować. Gildia.pl sklep Wydawnictwa Prószyński Media z jedną z największych baz komiksów w Polsce - blisko 390 tysięcy produktów - ma taki „Black Friday" kilka razy w miesiącu. To efekt specyfiki branży: limitowane nakłady przedsprzedażowe kupowane przez lojalnych kolekcjonerów, którzy o wyznaczonej godzinie, co do minuty, wchodzą się na stronę, żeby zdążyć przed wyprzedaniem nakładu.

To nie jest ruch, który da się „przeczekać". To powtarzalny, przewidywalny w czasie pik, w którym w ciągu jednej minuty na sklep spada kilkadziesiąt zamówień jednocześnie.

Punkt wyjścia: dobrze działający sklep na nowej platformie

W 2025 roku Gildia świadomie zdecydowała się na migrację na Magento - silnik klasy enterprise, lepiej przygotowany na duży katalog i rosnącą skalę niż poprzednie rozwiązanie. Pierwsze miesiące pracy na nowej platformie pokazały jednak, czego taka skala faktycznie wymaga od infrastruktury. W tym momencie do projektu dołączył zespół Kaliop Poland, przejmując odpowiedzialność techniczną za sklep.

Pierwszym krokiem nie było wdrażanie zmian na oślep, tylko audyt - świadomie ograniczony w czasie, żeby szybko wdrożyć konkretny plan działania, a nie trwać w tym miesiącami.

Dwa fronty optymalizacji: infrastruktura i kod

Audyt pokazał, że problemu nie da się rozwiązać samym „mocniejszym serwerem". To rozwiązanie działa, ale tylko do pewnego momentu, ograniczonego budżetem albo możliwościami dostawcy.

Dlatego prace poszły dwutorowo:

• Infrastruktura - przeniesienie sklepu na nowe środowisko z aktualnymi wersjami całego stosu technologicznego: systemu operacyjnego, języków programowania, bazy danych, wyszukiwarki. Sam ten krok dał wydajność praktycznie „za darmo".

• Kod - eliminacja wąskich gardeł zaszytych w oprogramowaniu sklepu. Zapytania, które przy niewielkim ruchu nie robią różnicy, przy dziesiątkach transakcji na minutę stają się realnym problemem. Priorytetem była ścieżka zakupowa: strona główna (odchudzona z niepotrzebnych zapytań), karta produktu, wyszukiwarka, a na końcu koszyk i finalizacja zamówienia - czyli miejsca, gdzie najłatwiej stracić sprzedaż tuż przed jej domknięciem.

Całość działa pod własnym monitoringiem wbudowanym w infrastrukturę od pierwszego dnia - nie doklejonym później - obejmującym 800 parametrów, z czego 50 kluczowych śledzonych na bieżąco.

Wybór hostingu: dedyk kontra chmura

Twardym ograniczeniem był budżet, rząd wielkości ok. 4 tys. zł miesięcznie na całą infrastrukturę (produkcja, testy, backupy). Porównano trzech dostawców: Scaleway, OVH i AWS, w dwóch modelach: pojedynczy serwer dedykowany vs. chmura z rozdzielonymi usługami.

Serwer dedykowany wypadał najtaniej na papierze, ale miał jedną istotną wadę: kupuje się go w konkretnym rozmiarze. Żeby mieć zapas mocy na przedsprzedaż, trzeba wziąć większą maszynę i płacić za nią całą dobę, cały miesiąc, żeby wykorzystać tę moc przez kilka godzin. AWS odpadł głównie ze względu na koszty transferu danych.

Ostatecznie wybór padł na model chmurowy u Scaleway, z trzech powodów:

• Elastyczne skalowanie - każdy komponent (aplikacja, baza, wyszukiwarka) skaluje się niezależnie i w szerszym zakresie niż u konkurencji, a w pakiecie było więcej m.in. szybsze dyski i kopie w dwóch strefach.

• Data center w Polsce - infrastruktura fizycznie w Warszawie.

• Wsparcie na każdym etapie wdrożenia.

Dodatkowym potwierdzeniem tego kierunku było wybranie Scaleway przez Komisję Europejską jako jednego z dostawców suwerennej chmury dla instytucji UE w ramach Cloud III DPS, sygnał, że dane pozostają w europejskiej jurysdykcji, co dla sklepu przetwarzającego dane klientów ma bezpośrednie znaczenie.

Architektura: trzy klocki, każdy z jednym zadaniem

Dzisiejsza produkcja to trzy oddzielne maszyny (plus środowisko testowe):

• Sklep - Magento za Varnishem (cache oddający gotowe strony, zanim Magento „się obudzi"), Nginx, PHP i Redis do sesji i koszyków. To komponent, który najmocniej pracuje o 12:00.

• Baza danych - MariaDB na osobnej maszynie, bez dzielenia zasobów z niczym innym, bo baza to jedyny element, którego nie da się schować za cache'em.

• Wyszukiwarka - OpenSearch, obsługujący przeszukiwanie 390 tysięcy produktów w ułamku sekundy.

Do tego dochodzi zewnętrzna warstwa Cloudflare, która odsiewa ruch niebędący realnymi klientami, w jednym z pików odbiła 7 milionów requestów w ciągu 3 godzin, z których żaden nie pochodził od klienta.

Kluczowa zaleta tej architektury: każdy komponent skaluje się osobno. Gdy monitoring pokazuje, że „grzeje się" baza - dokłada się mocy bazie, a nie całości.

Skalowanie na przedsprzedaż - proces, nie akcja

Z odpowiednim wyprzedzeniem przed znaną godziną startu przedsprzedaży serwer aplikacji skaluje się 1,5x–4x (maksimum), a baza danych 2x. Wyszukiwarka pozostaje bez zmian. Po szczycie ruchu wszystko wraca do normalnych parametrów.

Od grudnia proces ten powtórzono już osiemnaście razy, a każda przedsprzedaż kończy się analizą wykresów: co się przegrzało, co zaskoczyło, co poprawić przed następną. Dziś to ustandaryzowany schemat, a nie jednorazowa interwencja.

Jeden z takich cykli nauki dotyczył mechanizmu powiadomień o dostępności produktu, przy starcie przedsprzedaży serwer musiał jednocześnie obsłużyć falę zamówień i wysyłkę powiadomień, a mechanizm nie był projektowany pod taką skalę. Problem wykryto na monitoringu i zoptymalizowano, zanim wpłynął odczuwalnie na klientów.

Efekt biznesowy: nuda jako sukces

Jak ujął to jeden z klientów w komentarzu po przedsprzedaży: „nudno, bo nic się nie wysypało". Dla zespołu odpowiedzialnego za infrastrukturę to najlepsza możliwa recenzja. W szczycie ruchu sklep przyjmuje ponad jedno zamówienie na sekundę - dla porównania, konfiguracja sprzed zmian miała problemy już przy 30 zamówieniach na minutę.

Ile to kosztuje?

Pojedyncza przedsprzedaż - czyli kilka godzin pracy na powiększonych zasobach - to koszt rzędu kilkunastu złotych, mniej niż pół procenta miesięcznej opłaty za infrastrukturę. Osiemnaście przedsprzedaży od grudnia dało łącznie ok. 250 zł w ciągu dziewięciu miesięcy pików. Sedno modelu chmurowego: płaci się za zapas mocy wtedy, kiedy jest potrzebny, a nie przez cały miesiąc.

Podobne podejście zastosowano do backupów. Zamiast prostego, ale kosztownego snapshotu całej maszyny trzymanego w miejscu produkcyjnym, wdrożono trzy warstwy: jednorazowy snapshot migrowany od razu do tańszego archiwum, gdzie leży kilka dni, oraz osobną, lokalną kopię samej bazy danych - jedynego elementu, który trzeba umieć odtworzyć w minuty, a nie w godziny.

Trzy pytania na koniec:

Z tego doświadczenia zespół wyciąga trzy pytania, które warto sobie zadać przed spodziewanym wzrostem ruchu:

• Czy wiecie, gdzie boli? Nie „strona jest wolna", tylko która warstwa, w której minucie, przy jakim ruchu. Zgadywanie kosztuje więcej niż monitoring.

• Płacicie za zapas, czy za użycie? Większy serwer to najprostsza decyzja, ale działa tylko do pewnego momentu.

• Macie proces, czy mieliście projekt? Sklep, który rośnie, zmienia profil ruchu. Optymalizacja, która się „skończyła", jest optymalizacją pod sklep, którego już nie ma.