Co się psuje przy 10× ruchu: inżynieria skalowania sklepu internetowego

Przy 10× ruchu sklep internetowy prawie nigdy nie pada z jednego powodu. Psuje się warstwa po warstwie, w dość przewidywalnej kolejności: najpierw baza danych (wyczerpana pula połączeń, brak indeksów, zapytania N+1, blokady), potem brak cache i CDN (serwer renderuje w kółko to samo), następnie synchroniczne integracje z płatnościami, ERP czy marketplace, które przy obciążeniu zaczynają odpowiadać wolno albo w ogóle. Dobra wiadomość: każdy z tych punktów pęknięcia jest znany z góry i da się go wzmocnić, zanim ruch faktycznie przyjdzie. Skalowanie sklepu to nie kupienie mocniejszego serwera w nocy przed szczytem, tylko decyzje architektoniczne podjęte wcześniej.

Co pęka jako pierwsze i dlaczego

Wzrost ruchu nie działa liniowo. Dziesięć razy więcej odwiedzin to często sto razy więcej zapytań do bazy, bo każda strona uruchamia własną kaskadę odczytów. To dlatego sklep, który przy normalnym ruchu chodzi płynnie, potrafi przewrócić się w kilka minut po starcie kampanii albo po wejściu na nowy rynek. Warto rozłożyć to na czynniki, bo kolejność pękania jest niemal zawsze ta sama, a interwencje trzeba planować od najniższej warstwy w górę.

Baza danych: pierwsza ofiara skoku ruchu

Baza pada zwykle zanim cokolwiek widać na froncie. Winne są cztery rzeczy, które przy małym ruchu były niewidoczne. Pierwsza to zapytania N+1: strona listująca produkty odpytuje bazę raz po liście, a potem osobno o każdy produkt, kategorię i cenę, więc jeden widok generuje setki zapytań. Druga to brak indeksów na kolumnach używanych do filtrowania i sortowania, przez co baza skanuje całe tabele. Trzecia to blokady i locki przy równoległych zapisach, na przykład aktualizacji stanu magazynowego. Czwarta, najbardziej brutalna, to wyczerpanie puli połączeń: każda instancja aplikacji trzyma ograniczoną liczbę połączeń do bazy, a gdy zabraknie ich pod obciążeniem, kolejni użytkownicy po prostu czekają, aż upłynie timeout. Dokładanie serwerów aplikacyjnych wtedy pogarsza sytuację, bo każdy nowy serwer chce własnych połączeń do tej samej, przeciążonej bazy.

Brak cache i CDN: renderowanie tego samego w kółko

Jeśli każdy użytkownik dostaje stronę wyrenderowaną od zera, serwer wykonuje tę samą pracę tysiące razy dla treści, która się nie zmienia. Strona główna, karta produktu czy listing kategorii wyglądają tak samo dla większości odwiedzających w danej chwili, a mimo to platforma liczy je za każdym razem. Bez warstwy cache i bez CDN, który serwuje statyczne zasoby i buforowane strony blisko użytkownika, cały ruch uderza w Twój origin. Przy szczycie to właśnie tu marnuje się najwięcej mocy. Cache nie jest kosmetyką wydajnościową, tylko mechanizmem, który zdejmuje z bazy i aplikacji dużą część niepotrzebnej pracy.

Integracje synchroniczne jako wąskie gardło

Najbardziej podstępny punkt pęknięcia leży poza Twoim sklepem. Jeśli w trakcie składania zamówienia Twoja aplikacja czeka synchronicznie na odpowiedź bramki płatności, systemu ERP albo API marketplace, to Twoja wydajność jest zakładnikiem cudzych limitów. Gdy zewnętrzny system zwolni pod obciążeniem, wątki Twojej aplikacji blokują się w oczekiwaniu, pula wątków się wyczerpuje, a sklep przestaje odpowiadać nawet użytkownikom, którzy tylko przeglądają produkty. Rozwiązaniem jest oddzielenie tego, co musi się wydarzyć natychmiast (rezerwacja stanu, autoryzacja płatności), od tego, co może poczekać sekundę czy dwie w kolejce (synchronizacja z ERP, wysyłka do marketplace, e-mail potwierdzający). Praca asynchroniczna sprawia, że wolna integracja spowalnia jeden proces w tle, a nie cały sklep.

Stany magazynowe i overselling

Przy równoległych zamówieniach na ten sam produkt łatwo sprzedać więcej sztuk, niż faktycznie masz. Dwóch klientów widzi ostatnią sztukę, obaj klikają kup, a jeśli sprawdzenie i pomniejszenie stanu nie dzieje się w jednej, atomowej operacji, oba zamówienia przechodzą. Przy normalnym ruchu takie kolizje zdarzają się rzadko i giną w szumie. Przy szczycie stają się regułą, a każdy przypadek to koszt: anulowanie, zwrot, obsługa klienta i nadszarpnięte zaufanie. To problem inżynierii współbieżności, nie księgowości magazynowej, i rozwiązuje się go rezerwacją stanu w spójnej transakcji albo kolejkowaniem operacji na tym samym SKU.

Front pod obciążeniem i brak obserwowalności

Front też ma swoje granice. Ciężkie, nieoptymalne strony, które przy jednym użytkowniku ładują się akceptowalnie, pod obciążeniem robią się wolne, bo konkurują o te same zasoby serwera i sieci. Wolniejsza strona pod szczytem to realny koszt konwersji, dlatego wydajność frontu trzeba traktować jak wymaganie, nie jak dodatek. A nad tym wszystkim wisi problem, który jest gorszy niż każda pojedyncza awaria: brak obserwowalności. Jeśli nie masz metryk, logów i alertów, to w momencie skoku ruchu nie wiesz, czy pękła baza, cache, integracja czy front. Diagnozujesz na ślepo, w najgorszym możliwym momencie. Nie da się wzmocnić czegoś, czego nie widzisz.

Jak przygotować sklep na szczyt ruchu

Przygotowanie do wzrostu ruchu to praca inżynierska, którą wykonuje się przed szczytem, a nie w jego trakcie. Punktem wyjścia jest realny test obciążeniowy: symulacja ruchu na poziomie, którego się spodziewasz, a najlepiej wyraźnie powyżej, prowadzona na środowisku zbliżonym do produkcji. Load i stress test nie służą temu, żeby zobaczyć ładną zieloną kreskę, tylko żeby celowo znaleźć warstwę, która pęka pierwsza, i poznać liczbę, przy której to się dzieje. Dopiero znając ten limit, wiesz, co realnie wzmocnić. Poniżej kierunki, które w praktyce dają największą odporność.

• Warstwy cache i CDN: buforuj to, co się nie zmienia, i serwuj statyczne zasoby blisko użytkownika, żeby zdjąć pracę z origin.
• Kolejki i praca asynchroniczna: wszystko, co nie musi się wydarzyć natychmiast (ERP, marketplace, e-maile), wypchnij do kolejek, żeby wolna integracja nie blokowała sklepu.
• Rozdzielenie odczytu i zapisu: kieruj ciężkie odczyty do replik, żeby zapytania analityczne i listingi nie konkurowały z zapisami zamówień.
• Oddzielenie frontu (headless): niezależne skalowanie warstwy prezentacji i logiki sklepu, tak by szczyt na froncie nie przewracał backendu.
• Monitoring, alerty i budżety wydajności: metryki na każdej warstwie plus twarde progi, po przekroczeniu których dostajesz sygnał, zanim awaria dotknie klientów.

Mapa warstw sklepu: gdzie zwykle pęka przy 10× ruchu i czym to wzmocnić.

Skalowalność to decyzja architektoniczna, nie łatka

Najtrudniejsza prawda o skalowaniu jest taka, że większości tych rzeczy nie da się dorobić w tydzień przed szczytem. Rozdzielenie odczytu i zapisu, headless, kolejki czy sensowna obserwowalność to decyzje, które zapadają na etapie budowy platformy, bo dotykają jej fundamentów. Właśnie dlatego skalowalność projektuje się w fazie inżynieryjnej, a nie ratuje awaryjnie na produkcji. W praktyce Seedlight podchodzimy do tego dwuetapowo: architekturę odporną na wzrost ruchu zakładamy już w fazie Engineering frameworku BEAM, a wydajność, monitoring i reagowanie na szczyty pilnujemy potem w Maintenance and Growth. Jeśli sklep dopiero co przewrócił się pod ruchem albo regularnie zwalnia w szczycie, to często sygnał głębszy niż jeden bug: bywa, że platforma po prostu przestała nadążać za skalą biznesu. O tym, jak rozpoznać ten moment, piszemy w tekście o sygnałach wyrośnięcia z platformy SaaS.