Multi-region i geo-redundancja dla sklepu B2B

Kiedy multi-region ma sens

Multi-region nie jest dla każdego sklepu B2B i większość przypadków, w których ktoś o niego pyta, kończy się rekomendacją "zostań na jednym regionie, dodaj porządny CDN". To rozwiązanie z realnymi kosztami infrastruktury, operacji i utrzymania - decyzję podejmuj świadomie, nie modnie.

W mojej praktyce sensowne wdrożenia multi-region spełniają minimum dwa z trzech warunków. Pierwszy - faktyczna dystrybucja geograficzna klientów. Co najmniej 20-30% sprzedaży poza Polską, klienci w regionach oddalonych powyżej 80 ms od serwera głównego, ewentualnie różne strefy czasowe (sklep obsługujący USA i Azję). Drugi - twardy wymóg SLA. Kontrakty B2B z dużymi klientami często wymagają 99.9% uptime, multi-region dokłada do tego dziewiątkę i daje 99.99%, plus disaster recovery jako wymóg formalny w umowie. Trzeci - compliance regionalny. RODO trzyma dane w EU, dane azjatyckie idą do regionu Singapore, dane USA tylko w US z powodu HIPAA i podobnych regulacji.

Multi-region nie ma sensu w trzech sytuacjach, które widzę regularnie. Większość klientów w PL plus ościenne kraje (czyli "Europa Środkowa", do której z Warszawy jest 30-50 ms). Brak realnego wymogu SLA - klient mówi "musimy być dostępni", ale w kontrakcie nie ma kary za przestój. Mały zespół IT (1-3 osoby), który nie utrzyma drugiego regionu w stanie produkcyjnym, więc po roku okazuje się, że "zapasowy region nie działa już od 6 miesięcy, bo nikt go nie testował".

Dla 90% polskich sklepów B2B wystarcza minimalna kombinacja: serwer w eu-central-1 (Frankfurt) albo w polskim data center, globalny CDN (Cloudflare albo BunnyCDN) obsługujący obrazy, statyki i edge cache HTML, plus dobrze zoptymalizowany backend. To daje czas odpowiedzi poniżej 150 ms w całej Europie, co jest w pełni akceptowalne dla B2B.

CDN dla katalogów - dla większości sklepów wystarcza zamiast multi-region.

Active-passive vs active-active

Jeśli już zdecydowałeś, że multi-region ma sens, pierwsza decyzja architektoniczna to wybór między active-passive a active-active. To nie jest niuans techniczny, tylko fundamentalny wybór modelu kosztowego i operacyjnego.

Active-passive (znane też jako warm standby) wygląda tak: region główny - powiedzmy Frankfurt - obsługuje 100% ruchu. Region zapasowy ma replikę bazy, ale serwery aplikacji chodzą w trybie minimalnym (jeden niewielki node zamiast pełnego klastra). Failover ręczny albo automatyczny, w zależności od ambicji zespołu. Koszt jest umiarkowany - 1.3-1.5 raza single-region, bo zapasowa baza zjada zasoby, ale serwery aplikacji nie. Architektura prosta, mniej do testowania, jasne reguły propagacji danych.

Wady. Failover trwa typowo 5-30 minut, w zależności od tego, czy DNS się propaguje, czy masz globalny load balancer, czy serwery zapasowe trzeba podnieść. Region zapasowy nie jest testowany realnym ruchem - "obudzony" w momencie awarii potrafi pokazać, że nikt go nie testował od 3 miesięcy. Klienci z Europy Wschodniej i tak idą do Frankfurt, bo Warsaw stoi w roli zapasowej - nie zyskujesz na latencji.

Active-active (czyli true multi-region) wygląda zupełnie inaczej. Oba regiony obsługują ruch równolegle, routing geograficzny kieruje klienta z PL do Warszawy, a z DE do Frankfurt. Bazy synchronizowane dwukierunkowo. Klient zauważa awarię tylko w postaci minimalnego przeskoku latencji, bo drugi region przejmuje natychmiast. Plus - najlepsza latencja per klient, prawdziwa redundancja, oba regiony testowane non-stop. Minus - koszt 2-2.5 raza single-region, złożoność synchronizacji, konflikty zapisów wymagają zaprojektowanej strategii.

Rekomendacja: średnia hurtownia obsługująca PL plus DE/CZ - active-passive z Frankfurtu plus warm standby w Warszawie, ROI graniczne, ale do obronienia, jeśli kontrakt wymaga SLA. Duża firma z dystrybucją w całej UE - active-active w dwóch-trzech regionach, ale tylko jeśli masz zespół SRE minimum trzech osób. Bez zespołu SRE active-active to mina.

Replikacja bazy między regionami

Replikacja bazy jest najczęstszym wąskim gardłem multi-region. Wszystko inne (storage, sesje, cache) ma rozwiązania względnie znane. Bazą można się zranić długo i głęboko.

W MySQL i MariaDB najczęściej używana strategia to read replicas asynchroniczne. Source siedzi we Frankfurcie, replica w Warszawie, opóźnienie replikacji w zdrowym setupie to 50-200 ms. Odczyty puszczasz na replikę, mając świadomość lagu - klient właśnie wystawił fakturę, ale lista jego faktur na replice jeszcze tej faktury nie pokazuje. Zapisy zawsze idą na source. To jest model, który polecam jako pierwszy, bo jest prosty i ma znane tryby awarii.

Bidirectional replication (Galera Cluster, Group Replication w MySQL 8) pozwala na zapisy w obu regionach. Synchronizacja jest kosztowna, opóźnienia rosną liniowo z latencją sieci, a konflikty wymagają strategii rozstrzygania - last-write-wins to default, ale w zamówieniach widziałem to złamane przez zegary serwerów rozsynchronizowane o kilka sekund.

PostgreSQL ma swoje warianty. Streaming replication asynchroniczna działa podobnie jak MySQL. Logical replication pozwala replikować wybrane tabele (np. zamówienia tak, logi już nie). Multi-master przez BDR albo Citus jest możliwe, ale wchodzisz w obszar, w którym mała liczba osób na świecie ci pomoże.

W AWS warto rozróżnić Multi-AZ od Global Database. Multi-AZ to replikacja w obrębie tego samego regionu (failover w innym data center, ale wciąż Frankfurt) - to nie jest multi-region, choć marketing AWS sugeruje inaczej. Aurora Global Database to dopiero prawdziwa replikacja między regionami z opóźnieniem typowo poniżej sekundy.

W praktyce dla sklepu B2B z dominującym czytaniem (95% requestów to read - PLP, PDP, search), read replicas wystarczą. Zapisy (zamówienia, modyfikacje koszyka) trzymasz na master we Frankfurcie, replika w Warszawie obsługuje listy produktów, kategorie, wyszukiwarkę. Akceptujesz eventual consistency dla katalogu - to nie jest księgowość, klient zauważa lag tylko w wyjątkowych przypadkach.

Skalowanie bazy danych w sklepie B2B - bazowe techniki skalowania bazy, niezależnie od multi-region.

CDN i edge functions

CDN bywa nazywany "multi-regionem dla ubogich" i to złe określenie, bo dla wielu sklepów CDN jest po prostu lepszym rozwiązaniem od multi-region - tańszym, prostszym i wystarczającym.

Co CDN robi za ciebie samodzielnie. Obrazy, statyki, fonty - cache na 150+ węzłach globalnie, klient w Berlinie pobiera obrazy z węzła we Frankfurcie zamiast z Warszawy. HTML page cache dla niezalogowanych: PLP, kategorie, strona główna. API katalogu z cachem GET requestów i invalidation po update'ach. Geo-routing - klient z PL ląduje na najbliższym node CDN automatycznie.

Edge functions (Cloudflare Workers, AWS Lambda@Edge, Fastly Compute@Edge) dorzucają warstwę programowalności. Kod uruchamiany na edge, blisko klienta, pozwala na A/B testing per region, personalizację HTML (waluta, język, banner) bez powrotu do origin, rate limiting per region, logowanie i analytics zbierane blisko klienta. Dla sklepu B2B z międzynarodową bazą klientów to dramatycznie tańsze niż utrzymywanie multi-regionu z pełnym backendem.

Czego CDN nie zrobi. Zalogowanych klientów - cache nie może serwować spersonalizowanej zawartości (cennik kontraktowy klienta X). Operacji write - każdy POST i tak musi dojść do origin, nie ma od tego ucieczki. Danych w czasie rzeczywistym - stany magazynowe, ceny indywidualne wymagają zapytania do backendu, CDN może co najwyżej cache'ować je na 10-30 sekund.

Architektura "CDN plus jeden region" w działaniu wygląda tak:

Klient (DE) → Cloudflare edge (POP Frankfurt) → cache hit → odpowiedź 20 ms
                                              → cache miss → origin Warsaw → 50 ms
Klient (PL) → Cloudflare edge (POP Warsaw) → cache hit → 10 ms
                                           → cache miss → origin Warsaw → 15 ms

Większość requestów to cache hit, średnia latencja klienta z całej UE wychodzi w okolicach 30-60 ms. Bez wkładania prawdziwego multi-region, bez podwajania kosztów infrastruktury, bez zatrudniania drugiego DevOpsa.

Sesje, koszyki, stany

Fundamentalny problem multi-region to dane użytkownika. Sesja zaczęła się w regionie A, klient nagle robi request z regionu B, koszyk widać tylko w jednym z nich. Rozwiązania, w zależności od tolerancji złożoności.

Sticky sessions per region to najprostsze podejście. Klient zostaje routowany do swojego regionu na cały czas sesji, cookie zapisuje preferred-region. Klient z PL idzie do Warszawy nawet, gdy akurat siedzi w Berlinie. Prostota, brak konfliktów synchronizacji. Wada - klient za granicą ma gorszą latencję, jeśli jego sesja jest sticky do PL.

Sesje replikowane przez Redis sentinel multi-region. Stan sesji synchronizowany między regionami, każdy region może odczytać sesję każdego klienta. Elastyczność, prawdziwa redundancja. Minus - Redis multi-region jest drogi w utrzymaniu, opóźnienia replikacji generują race conditions w koszykach.

Stateless sesje w JWT. Cały kontekst sesji w tokenie po stronie klienta, weryfikowany w każdym regionie, bez server-side state. Najprostsza w architekturze multi-region. Wadą jest unieważnienie tokenu po logout (wymaga blacklisty po stronie serwera, co częściowo niweczy stateless), plus JWT z biegiem czasu się rozrasta i request headers robią się ciężkie.

Koszyk traktuję podobnie do sesji - albo sticky region, albo replikowany w Redis. W praktyce sticky wystarcza, bo koszyk powstaje i kupowany jest w jednej sesji, klient nie przeskakuje regionów.

Stany magazynowe to inna historia, bo źródłem prawdy jest ERP, nie sklep. Sklep cache'uje stany per region z invalidation przez webhook z ERP-a. Race condition (dwóch klientów w dwóch regionach próbuje kupić ostatnie 10 sztuk) rozwiązuje się przez rezerwację w ERP - sklep robi tylko optymistyczne sprawdzenie, finalna decyzja zapada centralnie.

Disaster recovery plan

Multi-region jest częścią strategii DR, ale samodzielnie nie wystarcza. Dobry plan ma kilka komponentów ułożonych razem, nie tylko replikę bazy w innym regionie.

Zacznij od dwóch liczb, które klient musi podpisać. RPO (Recovery Point Objective) to maksymalna ilość utraconych danych w wypadku awarii. Dla B2B typowo 5-15 minut - wymaga synchronicznej lub szybkiej asynchronicznej replikacji. RTO (Recovery Time Objective) to maksymalny czas niedostępności sklepu. Dla B2B typowo 15-60 minut - wymaga automatycznego failover albo udokumentowanej procedury manual z przepytanymi ludźmi.

Komponenty planu, których nie pomijam. Replikacja danych: streaming replication bazy do drugiego regionu, S3 cross-region replication dla obrazów produktów i PDF-ów, konfiguracja sklepu w gicie z deployem do każdego regionu z tego samego źródła. Procedury failover: udokumentowane kroki (DNS update, włączenie serwerów aplikacji w regionie B), skrypty automatyzujące (Terraform plus Ansible), regularne testy - tak zwane game days, kwartalnie, w oknie z niskim ruchem.

Monitoring zdrowia obu regionów. Health checks na każdy region, nie tylko URL ping, ale też business logic check (czy złożenie testowego zamówienia działa). DNS routing oparty na health (Route 53 health checks albo Cloudflare load balancing), alert do zespołu o degradacji zanim klienci zauważą.

Komunikacja z klientami w trakcie incydentu. Status page (statuspage.io, własna instancja). Proces powiadamiania klientów B2B z priorytetem (priority customers przez SMS lub telefon, reszta mailem). Postmortem publikowany w ciągu 48 godzin po incydencie - klienci B2B doceniają transparentność, brak postmortem jest sygnałem, że dostawca nie panuje nad jakością.

Niepokojąca obserwacja z mojej praktyki: około 60% incydentów to nie awaria infrastruktury, tylko błąd deploymentu albo konfiguracji. DR plan musi uwzględniać szybki rollback aplikacji, nie tylko regionalny failover - bo regionalnie ucieczka nie pomoże, jeśli broken kod jest w obu regionach.

Core Web Vitals dla sklepu - klient z dalekiego regionu mierzy CWV w pierwszej kolejności, więc multi-region wpływa na ranking.

FAQ

Ile kosztuje uruchomienie sklepu w drugim regionie? Active-passive z replikacją to typowo 30-50% dodatkowego kosztu infrastruktury względem single-region. Active-active podwaja koszt - bo masz pełen klaster aplikacji i baz w obu regionach. Plus jednorazowo 2-4 tygodnie pracy zespołu na konfigurację, testy i grę produkcji. Plus wzrost kosztów operacyjnych (zespół DevOps musi utrzymywać dwa razy więcej).

Czy hosting w PL wystarczy, gdy 30% klientów to DE? Najczęściej tak, jeśli masz porządny CDN i zoptymalizowany backend. Latencja PL-Berlin to 40 ms, jest akceptowalnie. Multi-region zaczyna się opłacać, gdy masz klientów oddalonych powyżej 100 ms od serwera - Szwecja, Hiszpania, USA. Dla 30% klientów w Niemczech CDN plus dobry hosting są lepszym wyborem niż drugi region.

Jak testować disaster recovery bez przerwy w sprzedaży? Game days - planowane testy DR w oknie z niskim ruchem (sobota rano, dla B2B). Failover na drugi region, weryfikacja, że wszystko działa, rollback do oryginalnego. Klienci nie zauważą, jeśli okno krótkie (do 5 minut przerwy jest akceptowalne dla większości B2B). Bez game days okazuje się w prawdziwy incydencie, że zapasowy region nie działa.

Co z RODO przy danych w wielu regionach? Dane EU muszą zostać w EU. Jeśli używasz multi-region z regionami poza EU (USA, Azja), potrzebujesz Standard Contractual Clauses albo Adequacy Decision dla państwa docelowego. Najprościej: trzymaj się EU regions - Frankfurt, Dublin, Sztokholm, Warszawa. Wtedy RODO jest spełnione bez dodatkowych klauzul.

Czy CDN zastąpi multi-region dla B2B? Dla 80% sklepów - tak. CDN obsługuje content delivery (obrazy, statyki, cache HTML), który stanowi większość problemu latencji. Multi-region dorzuca wartość tam, gdzie CDN nie cache'uje - zalogowani userzy, operacje write, dane w czasie rzeczywistym. Jeśli twój sklep B2B żyje głównie z zalogowanych klientów (cenniki indywidualne), CDN sam nie wystarczy. Jeśli z anonimowych odwiedzin (katalog, blog), CDN załatwi sprawę.

Co dalej

• Architektura sklepu B2B: Architektura dużych sklepów
• CDN przed sklepem: CDN dla katalogów
• Skalowanie bazy: Skalowanie bazy danych