Architektura e-commerce w branży modowej

Sprzedaż mody w kilku krajach wymaga czegoś więcej niż przetłumaczenia sklepu. Ceny, podatki, promocje i opcje dostawy różnią się między rynkami, a klienci oczekują spójnego doświadczenia w przeglądarce i aplikacjach mobilnych. Sezonowe szczyty stanowią dodatkowe wyzwanie: platforma musi działać szybko również przy gwałtownym wzroście ruchu.

Artykuł przedstawia architekturę sklepu modowego działającego na pięciu europejskich rynkach, ze wspólnym backendem dla web i mobile, danymi produktowymi zarządzanymi w PIM oraz analityką ścieżek klientów. Dowiedz się, jak odpowiednie połączenie dostarczania treści z brzegu sieci, wspólnego BFF i asynchronicznych integracji może zapewnić szybsze i bardziej spójne zakupy.

Kontekst

Klientem jest marka odzieżowa sprzedająca online bezpośrednio konsumentom w pięciu krajach: Francji, Hiszpanii, Polsce, Niemczech i Austrii. Każdy rynek ma własny język, walutę, stawki VAT, metody płatności i dostawy oraz lokalne promocje. Ruch jest duży i sezonowy: około 5 milionów wizyt miesięcznie, ze szczytami podczas wyprzedaży, gdy liczba odwiedzin rośnie wielokrotnie w ciągu kilku godzin.

Katalog produktów jest zarządzany w zewnętrznym PIM przez menedżerów produktu z całego świata. ERP odpowiada za stany magazynowe, ceny bazowe i realizację zamówień. Zdjęcia produktów, kluczowe dla konwersji w modzie, są dostarczane przez CDN. Firma chce analizować ścieżki użytkowników (user flow), aby optymalizować konwersję.

Klienci korzystają z wielu urządzeń: przeglądarek na komputerach i telefonach oraz natywnych aplikacji iOS i Android. Aplikacja mobilna jest wymaganiem klienta, a nie opcją: ma być pełnoprawnym kanałem sprzedaży z tym samym katalogiem, koszykiem i kontem użytkownika co sklep internetowy. Każdy kanał ma inne potrzeby dotyczące struktury danych, wielkości odpowiedzi i buforowania. Dlatego frontend web powstaje w Next.js (SSR/ISR dla SEO i szybkiego pierwszego renderowania stron kategorii i produktów), a między klientami a backendem znajduje się jeden wspólny BFF (Backend For Frontend) w Nest.js, obsługujący zarówno web, jak i aplikacje mobilne. BFF agreguje wywołania silnika commerce, PIM i ERP, dostosowuje odpowiedź do kanału oraz przejmuje buforowanie i obsługę sesji.

W przeciwieństwie do bankowości architekturę kształtują tutaj skala, wydajność i obsługa wielu rynków, a nie regulacje:

• duży i zmienny ruch, wymagający intensywnego buforowania w CDN i skalowania poziomego;
• pięć rynków z osobną lokalizacją treści, cen, podatków, płatności i dostaw;
• wiele kanałów (web, iOS, Android) ze wspólnym backendem, w tym wymagana aplikacja mobilna;
• katalog i multimedia zarządzane poza sklepem (PIM, DAM/CDN), synchronizowane z silnikiem commerce;
• integracja z istniejącym ERP jako źródłem prawdy o stanach magazynowych i zamówieniach;
• analityka ścieżek użytkowników bez pogarszania wydajności strony.

Istniejące systemy: PIM, ERP.

Sklep modowy: kontekst systemu

Sklep B2C działający w pięciu krajach na AWS. PIM i ERP pozostają źródłem prawdy o produktach, stanach magazynowych i zamówieniach.

Rysunek 1. Diagram C1 - Kontekst systemu: sklep modowy

Sklep modowy: kontenery na AWS

Jeden BFF dla web i mobile. PIM i ERP są synchronizowane w tle przez SNS + SQS.

Rysunek 2. Diagram C2 - Kontenery: sklep modowy na AWS

Obsługa wielu rynków

Jedna domena i jedna instalacja sklepu obsługują wszystkie pięć rynków; wybór rynku odbywa się na brzegu sieci. Na podstawie geolokalizacji IP (nagłówek CloudFront-Viewer-Country) CloudFront przekierowuje pierwszą wizytę na ścieżkę z prefiksem językowo-regionalnym (np. /pl-pl/, /de-at/) i przekazuje kraj do storefrontu Next.js. Storefront renderuje stronę we właściwym języku i wysyła rynek oraz język do BFF w nagłówkach X-Market i X-Locale. Na ich podstawie BFF pobiera z silnika commerce ceny, VAT, dostępność i metody płatności obowiązujące w danym kraju oraz treści marketingowe dla tego rynku. Wyrenderowany HTML jest buforowany w CDN osobno dla każdej wersji językowo-regionalnej, więc kolejne wizyty z tego samego kraju trafiają do pamięci podręcznej na brzegu sieci bez wywołań backendu.

Ręczny wybór rynku jest zapisywany w pliku cookie i ma pierwszeństwo przed geolokalizacją; użytkownicy z krajów spoza pięciu obsługiwanych rynków trafiają na /en/ z selektorem rynku. Aplikacja mobilna nie korzysta z przekierowań: rynek wybrany przy pierwszym uruchomieniu jest wysyłany w nagłówku X-Market przez ten sam CloudFront i WAF do BFF.

Routing rynku na podstawie geolokalizacji CloudFront

Pięć rynków: FR, ES, PL, DE, AT. Geolokalizacja wybiera tylko pierwszy rynek; później ścieżka URL określa treści, ceny i klucz pamięci podręcznej.

Rysunek 3. Routing rynku na podstawie geolokalizacji CloudFront

BFF (Backend For Frontend)

BFF to wzorzec, w którym między aplikacjami klienckimi a usługami backendowymi znajduje się dedykowana warstwa API, zaprojektowana wokół potrzeb frontendu, a nie struktury domeny. Zamiast zmuszać storefront i aplikację mobilną do osobnego wywoływania silnika commerce, wyszukiwarki, CMS i Cognito oraz składania odpowiedzi po stronie klienta, BFF wykonuje te wywołania, agreguje wyniki i zwraca jeden model widoku dopasowany do ekranu. Przykładowo strona produktu otrzymuje cenę w walucie rynku, dostępność, zdjęcia i treści marketingowe w jednym żądaniu.

W tej aplikacji BFF realizuje trzy cele. Po pierwsze, wielokanałowość: web i mobile korzystają z tego samego kontraktu, ale mobile może otrzymać lżejszą odpowiedź bez pól potrzebnych wyłącznie do SSR. Po drugie, obsługa wielu rynków: nagłówek X-Locale jest interpretowany w jednym miejscu, a logika wyboru cennika, VAT, płatności i języka nie jest powielana w każdej aplikacji. Po trzecie, wydajność i odporność: BFF przechowuje pamięć podręczną odpowiedzi w Redis, ogranicza liczbę wywołań backendu przy 5 milionach wizyt miesięcznie i izoluje frontend od zmian w silniku commerce lub PIM. Zmiana integracji oznacza wtedy zmianę w BFF, a nie aktualizację aplikacji mobilnej oczekującą na zatwierdzenie w sklepie z aplikacjami.

Czwartym celem jest bezpieczeństwo. BFF jest jedynym publicznie dostępnym API, więc silnik commerce, wyszukiwarka, PIM i ERP nie są dostępne z internetu, a ich klucze i adresy nie trafiają do przeglądarki ani pakietu aplikacji mobilnej. BFF weryfikuje token Cognito przy każdym żądaniu, a dopiero potem wywołuje backend przy użyciu własnych poświadczeń usługowych, dzięki czemu frontend nigdy nie ma uprawnień szerszych niż sesja użytkownika. W kanale web BFF przechowuje sesję w pliku cookie httpOnly z flagami Secure i SameSite zamiast tokenu w localStorage, co ogranicza możliwość kradzieży tokenu przez XSS; w kanale mobile obsługuje token odświeżania i jego rotację. Ponadto BFF ogranicza liczbę żądań na użytkownika i adres IP, waliduje dane wejściowe, ogranicza pola odpowiedzi do potrzeb ekranu, aby nie ujawniać danych wewnętrznych, oraz zapisuje żądania z identyfikatorem korelacji na potrzeby audytu i debugowania.

BFF jako stabilny kontrakt

Frontend i usługi backendowe można wymieniać niezależnie. Tylko BFF zna obie strony, a kontrakt /v1 pozostaje bez zmian.

Rysunek 4. Diagram: BFF jako stabilny kontrakt dla wymiennych frontendów

Analityka ruchu użytkowników

Ścieżki użytkowników są śledzone po stronie klienta przez lekki SDK zdarzeń (web w storefroncie, natywny w aplikacji mobilnej), który wysyła zdarzenia clickstream (page_view, product_view, add_to_cart, checkout_step, purchase) z anonimowym identyfikatorem sesji, rynkiem i kanałem, po uzyskaniu zgody na pliki cookie zgodnie z RODO. Zdarzenia przepływają przez Amazon Kinesis Data Streams i Firehose do jeziora danych w S3 w formacie Parquet. Glue kataloguje schemat, a Athena i QuickSight pozwalają budować lejki konwersji, analizować ścieżki i porównywać rynki bez utrzymywania hurtowni danych. Gotową podstawą jest rozwiązanie Clickstream Analytics on AWS, które udostępnia SDK web/iOS/Android, potok przyjmowania danych oraz wbudowane raporty ścieżek, retencji i lejków. Warstwa AI pracuje na tych samych danych: Amazon Q w QuickSight odpowiada na pytania w języku naturalnym („dlaczego konwersja w Austrii spadła w tym tygodniu”), model w Amazon Bedrock podsumowuje najczęstsze ścieżki i miejsca porzucenia oraz wykrywa anomalie w lejku, a Amazon Personalize uczy się na podstawie tych samych zdarzeń i zwraca rekomendacje produktów do BFF. Zdarzenia zawierają identyfikator sesji, a nie dane osobowe, więc analityka i AI działają na danych zanonimizowanych, a powiązanie z profilem klienta następuje wyłącznie po stronie silnika commerce, za zgodą użytkownika.

Komponenty:

• SDK analityczny: web (storefront) i mobile (iOS, Android), uzyskanie zgody przed wysyłaniem
• Amazon Kinesis Data Streams: przyjmowanie zdarzeń w czasie rzeczywistym
• Amazon Kinesis Data Firehose: buforowanie, konwersja do Parquet, zapis w S3
• Amazon S3: jezioro danych zdarzeń, partycjonowane według daty i rynku
• AWS Glue: katalog schematów, transformacje
• Amazon Athena: doraźne zapytania SQL
• Amazon QuickSight + Amazon Q: pulpity lejków i ścieżek, pytania w języku naturalnym
• Amazon Bedrock: podsumowywanie ścieżek, wykrywanie anomalii w lejku, generowanie wniosków
• Amazon Personalize: rekomendacje produktów zwracane przez BFF
• alternatywnie: Clickstream Analytics on AWS jako gotowy pakiet SDK + potok danych + raporty

Analityka ruchu na AWS

Aplikacje klienckie wysyłają anonimowe zdarzenia po uzyskaniu zgody. Surowe zdarzenia trafiają do S3 jako Parquet; stamtąd dane odczytują SQL, pulpity analityczne i AI.

Rysunek 5. Diagram: analityka ruchu na AWS