Architektura dużych sklepów B2B - skalowanie, headless, search, cache

W skrócie

• 1. Monolit, jeśli możesz - większość polskich B2B w skali do 100 M zł obrotu nie potrzebuje microservices
• 2. Microservices, gdy musisz - przy 5+ zespołach, multi-region, multi-brand
• 3. Headless, gdy masz uzasadnienie - wiele frontów (web + mobile + kiosk), nie „bo trzeba"
• 4. Search dedykowany (Algolia / Elastic / OpenSearch) od ~5k SKU
• 5. Cache wielowarstwowy od dnia zero: app cache → Redis → Varnish → CDN
• 6. Kolejki dla wszystkiego co asynchroniczne - RabbitMQ, Redis Streams, AWS SQS
• 7. CDN dla obrazów i statyków od dnia zero - Cloudflare, BunnyCDN, AWS CloudFront

Co to znaczy „duży sklep B2B"

Definicja robocza, na której pracuję:

• 10k+ SKU w aktywnym katalogu (produkty pokazywane klientowi, nie zarchiwizowane)
• 100+ aktywnych kontrahentów z indywidualnymi cennikami
• 1k+ zamówień miesięcznie
• 3+ kanały wymiany danych (sklep + Allegro + EDI z siecią + system zakupowy klienta)
• 2+ integracje krytyczne (ERP + PIM + OMS / WMS)

W tej skali architektura zaczyna być dźwignią - albo cię pcha, albo cię ciągnie w dół. Poniżej tego - każda platforma typu Magento Open Source lub Shopware Community z domyślnym deploymentem da radę. Powyżej - decyzje strategiczne dają mierzalny ROI.

Monolit czy microservices

Najczęstsze pytanie ostatnich lat, najczęściej źle postawione.

Monolit w kontekście sklepu B2B to: jedna aplikacja, jedna baza danych, jedno repozytorium kodu, jeden deployment. Magento Open Source, Shopware 6, PrestaShop - to monolity.

Microservices to: wiele małych aplikacji, każda ze swoją bazą danych, własnym deploymentem, komunikujących się przez API lub message broker. Każdy serwis ma jedno zadanie (catalog, cart, checkout, search, customer).

Kiedy monolit:

• Jeden zespół rozwija sklep
• Skala do ~50 M zł obrotu rocznego, do ~50k SKU
• Krótki time-to-market priorytet
• Wymóg „działającego sklepu" wyższy niż „eleganckiej architektury"
• 95% polskich B2B w skali średniej

Kiedy microservices:

• 5+ niezależnych zespołów (każdy może deployować niezależnie)
• Multi-region (sklep PL + DE + UK z różnymi politykami danych)
• Multi-brand (kilka marek dzielących pewne komponenty)
• Skala > 100 M zł obrotu, > 100k SKU
• Niezależne lifecykle różnych domen biznesowych

Antywzorzec: mikroserwisy „bo nowoczesne". Microservices są drogie - w infrastrukturze, operacjach, debugowaniu. Jeśli twój zespół to 6 osób i kod ma jeden ścieżkę deployment'u - nie potrzebujesz mikroserwisów.

Monolit vs. microservices - pełna analiza.

Headless commerce - kiedy ma sens

Headless to wyodrębnienie frontendu od backendu e-commerce, komunikacja przez API. Backend (Magento, Shopware) wystawia produkty, ceny, koszyk, checkout przez REST/GraphQL. Frontend (React, Vue, Next.js, Nuxt) konsumuje.

Kiedy tak:

• Mobile app obok strony webowej - bez headless robisz UI dwa razy
• Mobile-first UX z aspiracjami performance (LCP < 1.5s)
• Frontend team wymaga nowoczesnego stacku (Next.js, Nuxt)
• Embedded katalog w systemie klienta (np. punchout jako iframe lub web component)
• Sklep B2B z kioskami / punktami POS dzielącymi backend

Kiedy nie:

• Klasyczny sklep B2B, klienci kupują z desktopa, prosty UI
• Mały zespół deweloperski, krótki TTM
• Brak doświadczenia z modern frontend (Next/Nuxt) - uczysz się w trakcie projektu = pułapka

Headless commerce dla B2B.

Search - kiedy MySQL przestaje wystarczać

Magento, Shopware i większość platform zaczyna z full-text search w MySQL. Działa do ~5k SKU. Powyżej:

• Filtrowanie po 5+ atrybutach: 2-8 sekund
• Search po opisie + nazwie: 3-15 sekund
• PLP z paginacją: timeout

Wtedy potrzebujesz dedykowanego search:

Elasticsearch / OpenSearch - open-source, full-text search engine. Magento 2.4+ wymaga go z urzędu. Shopware ma opcjonalnie. Self-hosted lub managed (AWS OpenSearch, Elastic Cloud).

Algolia - SaaS, najlepsze UX (typeahead, instant search, custom ranking). Dla dużych katalogów drogie (per query, per record).

Meilisearch - open-source, młodszy, mniejszy ekosystem ale szybko rośnie.

Typesense - podobnie.

Wskaźniki, kiedy migrować:

• LCP na PLP > 2.5s
• Tail latency p95 > 3s
• Klienci skarżą się „wolny sklep"
• Powyżej 10k SKU + filtry

Search Algolia vs. Elasticsearch - analiza.

Cache - warstwowy, od dnia zero

Cache w sklepie B2B to nie luksus. To wymóg. Bez warstwowego cache sklep z 50k SKU i 100 kontrahentami będzie wolny zawsze, niezależnie od hardware.

Cztery warstwy:

1. App-level cache (PHP/Node).

• Cache obiektów w pamięci (APCu, OPcache, application memory)
• Dane konfiguracyjne, encje produktów, kontrahentów
• TTL krótki (sekundy do minut)

2. Distributed cache (Redis / Memcached).

• Sesje użytkowników
• Cache cen kontraktowych (kontrahent × SKU × ilość)
• Cache stanów magazynowych
• Cache wyników search (frequent queries)
• TTL minuty do godzin

3. Full-page cache (Varnish / Fastly).

• Cache całych stron HTML dla gości
• Cache PLP, PDP, kategorii dla niezalogowanych
• Dla zalogowanych - selektywny (np. tylko obrazki, nie HTML)
• TTL minuty do dni

4. CDN edge cache (Cloudflare, BunnyCDN, AWS CloudFront).

• Statyki: obrazy, CSS, JS, fonty
• Możliwie dynamic content (z politykami unique-vary)
• Edge nodes na świecie - szybkie dla zagranicznych klientów

Każda warstwa ma swój koszt i zysk. Brak którejkolwiek = trzy razy więcej obciążenia w niższych warstwach.

Cache wielowarstwowy.

Kolejki - must-have dla integracji

Wszystko, co nie jest synchronicznym wymogiem koszyka klienta - przez kolejkę.

Co przez kolejkę:

• Zamówienie → ERP (sklep nie czeka aż ERP zapisze)
• Synchronizacja produktów ERP → sklep
• Synchronizacja stanów ERP → sklep
• Wysyłka emaila po zamówieniu
• Synchronizacja z BaseLinkerem / Allegro
• Aktualizacja indeksu search

Co synchronicznie:

• Walidacja koszyka (czy stan na sztuk się zgadza)
• Walidacja limitu kredytowego przy checkout'cie
• Płatność online (klient czeka na potwierdzenie)
• Wyświetlanie produktu / kategorii klientowi

Technologie:

• RabbitMQ - najczęściej w PHP/Symfony, dojrzałe
• Redis Streams - lekkie, dla mniejszych skala
• AWS SQS - managed, dla AWS-hostowanych
• Kafka - dla bardzo dużych skal (rzadkie w polskim B2B)
• Symfony Messenger - abstrakcja, działa nad każdym z powyższych

Kolejki RabbitMQ i Redis.

CDN - od dnia zero

CDN ma sens nawet dla małego sklepu. Powody:

• Obrazy produktów ładowane z edge node = LCP poprawione o setki ms
• Brotli, HTTP/2, HTTP/3 - bez konfiguracji
• DDoS protection - wbudowane
• WAF (Web Application Firewall) - wbudowane

Wybór CDN:

• Cloudflare - najpopularniejszy, ma free tier, prosty setup
• BunnyCDN - tańszy, polski / europejski hosting, popularny wśród polskich e-commerce
• AWS CloudFront - dla projektów na AWS
• Fastly - droższe, programowalne edge (VCL)

Dla typowego polskiego B2B: Cloudflare lub BunnyCDN. Cena: 50-500 zł / mies. zależnie od ruchu.

CDN dla katalogów 10k+ SKU.

Baza danych - skalowanie czytanego ruchu

W dużym sklepie 80% obciążenia DB to odczyt (przeglądanie katalogu), 20% zapis (zamówienia, panel admina). Skalowanie:

1. Master-slave replication. Pisanie do master, czytanie ze slave'ów. Magento, Shopware to wspierają. Slave do raportów, master do operacyjnego.

2. Read replica dla raportów. Osobny slave tylko dla zapytań analitycznych (BI, dashboardy). Żeby nie obciążać operacyjnej bazy.

3. Sharding. Dzielenie danych na shardy (np. produkty A-M na shard 1, N-Z na shard 2). Drogie, skomplikowane. Rzadko sensowne w polskim B2B.

4. Database per service (przy microservices). Każdy serwis ma swoją bazę, własne ograniczenia. Skala wyższa, złożoność większa.

5. MariaDB / Percona zamiast standardowego MySQL. Lepszy performance, dedykowane optymalizacje. Migracja prosta.

6. PostgreSQL. Dla niektórych projektów lepszy niż MySQL - szczególnie gdy dużo JSON-ów (atrybuty), analytics.

Skalowanie bazy danych.

Observability - bez tego latasz na ślepo

Sklep w skali musisz mierzyć. Cztery filary:

1. Logs. Strukturyzowane (JSON), centralne (ElasticStack, Loki, Datadog).

2. Metrics. Per-endpoint czasy odpowiedzi, error rate, throughput. Prometheus + Grafana, lub managed (Datadog, New Relic).

3. Traces. Distributed tracing - pokazuje gdzie czas się gubi (sklep → ERP → DB → cache). OpenTelemetry, Jaeger, Datadog APM.

4. Alerts. Pager (Opsgenie, PagerDuty) na P1 incydenty. Brak alertów = klient powie ci pierwszy że sklep nie działa.

Koszt: 1-5 tys. zł / mies. dla średniego sklepu. Bez tego - nie zauważysz że indeksowanie się zaciął na 3 dni.

Deployment - CI/CD obowiązkowe

Bez automatycznego deploy:

• Deploy ręczny zajmuje 30-60 minut
• Człowiek czasem pominie krok (np. cache:flush)
• Rollback po awarii - kolejne 30 minut
• Wieczorne deploye dla bezpieczeństwa = zmęczenie deweloperów

Z CI/CD (GitHub Actions, GitLab CI, Jenkins):

• Deploy w 5-15 minut
• Testy automatyczne przed deploy
• Blue-green deployment (bez downtime)
• Rollback w sekundach (poprzedni release wciąż żyje)

Wdrożenie CI/CD dla średniego sklepu: 30-80 tys. zł setup, oszczędza 100+ godzin dev/rok.

Hosting - gdzie postawić sklep B2B

Bare-metal (Hetzner, dedykowane).

• Plus: największa moc / złotówka
• Minus: ręczne zarządzanie, brak auto-scalingu
• Dla kogo: średnich sklepów z stabilnym ruchem

Chmura publiczna (AWS, GCP, Azure).

• Plus: skalowanie, managed services
• Minus: drogie przy stałym ruchu (vs. bare-metal)
• Dla kogo: dużych sklepów z piku ruchu, multi-region

Hybryda.

• Plus: tańszy stały hosting + chmura na piki
• Minus: bardziej skomplikowane operacje

Polski hosting specjalistyczny (Hostersi, IQ PL).

• Plus: polskie wsparcie, znajomość polskich klientów
• Minus: mniejsza skala vs. globalne chmury

Dla typowego polskiego B2B 10-50 M zł obrotu - bare-metal Hetzner lub polski managed hosting. Koszt: 3-15 tys. zł / mies.

FAQ

Czy mogę zacząć z monolitem i przejść do microservices później? Tak. Większość udanych microservices wyrosło z monolitów. Klasyczny pattern: strangler fig - wyodrębniasz po jednym serwisie z monolitu. Bezpieczne, ale wymagające czasu.

Czy headless oznacza microservices? Nie. Headless to wyodrębnienie frontendu. Backend może być monolitem. Można mieć headless monolit (Magento z PWA Studio) lub headless microservices (commercetools + Next.js).

Co wybrać dla nowego sklepu 30k SKU, jeden zespół 5 osób? Monolit (Magento OS lub Shopware CE), Elastic, Redis, Varnish, CDN. Bez headless. Bez microservices. Działa, mieści się w budżecie, skaluje do 50-80 M zł obrotu.

Czy Kubernetes ma sens dla sklepu? Powyżej 4-5 deployment'ów (np. monolit sklepu + middleware + worker'y + cron'y) - tak, Kubernetes pomaga. Poniżej - Docker Compose lub klasyczne deploye wystarczą.

Czy AWS jest droższy niż polski hosting? Tak, znacznie. Dla stałego ruchu polski hosting jest 30-60% tańszy. Dla skali z pikami (Black Friday × 10) - chmura wygrywa. Dla projektów globalnych (multi-region) - chmura jedyna opcja.

Co dalej

• Konkretne obszary: Headless, Monolit vs. microservices, Kolejki, Search
• Cache i CDN: Cache warstwy, CDN
• Baza danych: Skalowanie DB
• Wydajność (pillar pokrewny): Wydajność e-commerce
• Integracje: pillar /integracje