10 tysięcy SKU to nie jest duży sklep

Dlaczego SKU nie mierzy niczego

Katalog to tabela. Baza danych nie ma nic przeciwko tabelom z pięćdziesięcioma tysiącami wierszy - to nie jest wyzwanie od dwudziestu lat. Jeśli twój sklep muli przy 10 tys. produktów, przyczyną nie jest liczba produktów.

Sklep B2C z 50 tys. SKU ma jedną cenę na produkt, jeden magazyn, anonimowych użytkowników i pełnostronicowy cache, który obsługuje 90% ruchu. To jest, z punktu widzenia architektury, prosty przypadek przy dowolnej liczbie wierszy.

Sklep B2B z 3 tys. SKU może mieć 200 kontrahentów, z których każdy widzi inną cenę i inną dostępność. Cache pełnostronicowy jest bezużyteczny, bo nie ma dwóch użytkowników widzących to samo. I to jest trudny przypadek, mimo szesnastu razy mniejszego katalogu.

Trzy miary, które coś znaczą

Zamiast liczby SKU warto policzyć trzy rzeczy.

Współbieżność zalogowanych. Ilu kontrahentów pracuje w sklepie jednocześnie w poniedziałek o 10:00. To ta liczba decyduje o obciążeniu, bo każdy z nich generuje ruch, którego nie da się zcache'ować globalnie. Trzydziestu zalogowanych kontrahentów B2B potrafi obciążyć system bardziej niż tysiąc anonimowych sesji B2C.

Liczba wariantów ceny. Iloczyn kontrahentów i indeksów, ograniczony do tego, co realnie się wyświetla. To jest rozmiar problemu cenowego - i to jest liczba, która rośnie szybciej, niż ktokolwiek zakłada przy pierwszym wdrożeniu.

Liczba systemów, które muszą się zgadzać. ERP, PIM, WMS, marketplace, EDI. Każdy dołożony system to nie plus jeden - to plus wszystkie pary, które trzeba utrzymać spójne. Przy trzech systemach masz trzy relacje, przy pięciu masz dziesięć.

Mnożenie, które zabija

Skala w B2B jest iloczynem, nie sumą. To jest cała różnica.

Dwustu kontrahentów razy trzy tysiące indeksów to sześćset tysięcy potencjalnych cen. Nie policzysz ich wszystkich z góry i nie zcache'ujesz na zapas - większość z nich nikt nigdy nie zobaczy, ale nie wiesz z góry które. Dlatego cache musi być leniwy, z kluczem (kontrahent, indeks), i dlatego strategia cache w B2B wygląda inaczej niż wszystko, co znajdziesz w poradnikach o wydajności sklepów.

Dołóż do tego progi ilościowe i okazuje się, że cena zależy jeszcze od zawartości koszyka. Wtedy „cache ceny" przestaje być pojęciem, a zaczyna być pytaniem „ceny czego". Rozbieram to w tekście o cennikach kontraktowych.

Jak siebie zmierzyć

Jeśli chcesz jednej liczby, która mówi coś sensownego o twojej skali, użyj tej:

Ilu użytkowników jednocześnie widzi dane, których nie da się współdzielić.

Poniżej dziesięciu - jesteś małym sklepem, niezależnie od katalogu. Standardowa platforma wystarczy, cache warstwowy jest przesadą.

Kilkadziesiąt - zaczynasz. Cache per kontrahent przestaje być opcjonalny, integracja z ERP musi być asynchroniczna, bo synchroniczna właśnie zaczęła cię ograniczać.

Powyżej stu jednocześnie - jesteś dużym sklepem i możesz mieć przy tym dwa tysiące produktów. Wtedy warto czytać o skalowaniu bazy i o kolejkach, a nie o tym, jak przyspieszyć listing.

Liczba SKU zostaje w prezentacji dla zarządu. Do projektowania architektury nie nadaje się do niczego.