Jedna instancja czy osobne instalacje? Odpowiedź bez owijania w bawełnę
Multistore na jednej instancji Magento ma sens wyłącznie wtedy, gdy Twoje marki współdzielą przynajmniej 70% katalogu produktów, tę samą bazę magazynową oraz spójną architekturę integracji z ERP. Jeśli prowadzisz dwa podmioty gospodarcze z osobnymi bazami Subiekta GT lub Comarch ERP Optima, odrębnymi zespołami e-commerce i całkowicie różnym asortymentem, jedna instancja stanie się długiem technologicznym, za który zapłacisz podwójnie przy każdym wdrożeniu poprawek. Realizując wdrozenia Magento 2 i Adobe Commerce, regularnie rozplątujemy monility, które miały oszczędzać na hostingu, a generują tysiące złotych strat przy każdej awarii wdrożeniowej.
Co to właściwie jest Website, Store i Store View w architekturze Magento 2.4.7?
Wielu właścicieli sklepów myli poziomy konfiguracji w Magento, co prowadzi do błędnych decyzji architektonicznych na etapie briefu. Silnik Adobe opiera się na trójstopniowej hierarchii:
- Website (Strona): Najwyższy poziom logiczny. To tutaj definiujesz walutę bazową (Base Currency), konta klientów (współdzielone globalnie lub unikalne dla danej domeny), stawkę podatkową oraz przypisanie do magazynów w ramach Multi-Source Inventory (MSI). Jeśli drugi sklep ma rozliczać się w EUR jako walucie bazowej transakcji bez przewalutowań w locie, potrzebujesz osobnego Website.
- Store (Sklep): Odpowiada za strukturę drzewa kategorii. Dwa sklepy w ramach jednego Website mogą mieć zupełnie inne menu, ale współdzielą koszyk, ceny bazowe i konta użytkowników.
- Store View (Widok sklepu): Najniższy poziom, stworzony głównie pod wersje językowe (np.
pl_PL,en_GB,de_DE). Zmienia wyłącznie etykiety, tłumaczenia atrybutów, layouty motywu (np. child theme w Hyvä) oraz widoczność poszczególnych widżetów.
Błąd w doborze tego podziału mści się natychmiast: jeśli spróbujesz obsłużyć rynek niemiecki i polski na poziomie Store View zamiast Website, nie ustawisz odrębnych cen bazowych netto dla tych samych SKU bez zewnętrznych modułów ingerujących w tabele catalog_product_entity_decimal.
Kiedy jedna instancja (Multistore) oszczędza setki roboczogodzin?
Jedna instalacja Magento 2.4.7 postawiona na PHP 8.3 i OpenSearch 2.12 to ogromna oszczędność w ściśle określonych scenariuszach biznesowych:
- Wspólny stan magazynowy (B2C + B2B): Sprzedajesz ten sam towar do klienta detalicznego i hurtowego. B2C działa na domenie
sklep.pl, B2B na subdomenie z ukrytymi cenami po zalogowaniu. Dzięki MSI rezerwacje towaru schodzą z tej samej puli bez opóźnień asynchronicznych konektorów. - Ekspansja zagraniczna (Cross-border) z jednego magazynu: Towar wysyłasz z Polski przez InPost i DHL, ale masz dedykowane domeny
twojmarka.deitwojmarka.cz. Ceny produktów konfigurujesz na poziomie Website per rynek, a layout dopasowujesz przez motywy potomne w Hyvä Themes. - Wspólny stack technologiczny i deployment: Jeden proces CI/CD, jedno repozytorium Git, pojedyncze uruchomienie
bin/magento setup:upgradeibin/magento setup:di:compiledla wszystkich brandów. Aktualizacja łatek bezpieczeństwa Magento (np. Security Patch 2.4.7-p1) zajmuje godziny, a nie dni robocze.
W projektach w SISL rekomendujemy multistore wyłącznie wtedy, gdy operacje magazynowe i procesy fakturowania dają się zamknąć w jednym schemacie logicznym. W każdym innym wypadku wspólna baza danych staje się wąskim gardłem.
Gdzie Multistore zamienia się w koszmar techniczny i organizacyjny?
Z pozoru tańsze rozwiązanie staje się pułapką, gdy zderza się z rzeczywistością operacyjną polskiego e-commerce. Poniżej zestawienie ryzyk, które musisz przekalkulować przed podjęciem decyzji:
1. Konflikty integracji ERP (Comarch Optima vs Subiekt nexo/GT)
Jeśli Marka A korzysta z Subiekta GT, a nowo przejęta Marka B z Comarch ERP Optima, próba wpięcia dwóch różnych integratorów (np. przez WebAPI i szynę danych) w jeden schemat bazy Magento kończy się wyścigiem procesów (race condition). Kolejki asynchroniczne bin/magento queue:consumers:start zaczynają blokować tabele zamówień, a mapowanie statusów płatności z Przelewy24 czy PayU rozjeżdża się na poziomie webhooków.
2. KSeF i fakturowanie z wielu podmiotów prawnych (różne NIP-y)
Od momentu wejścia obowiązkowego Krajowego Systemu e-Faktur każda transakcja musi być precyzyjnie przypisana do certyfikatu i tokenu autoryzacyjnego danego NIP-u. Wiele gotowych modułów integrujących KSeF z Magento 2 obsługuje konfigurację wyłącznie na poziomie default (globalnym), nie pozwalając na per-website token scope. Oznacza to konieczność customowego przepisywania modułu lub ryzyko wysyłki faktur Marki B na konto skarbowe Marki A.
3. Błąd ludzki lub deweloperski kładzie cały biznes
Pojedynczy błąd krytyczny Type error: Return value of... must be of the type string, null returned w module checkoutu wprowadzony na sklepie B wyłącza koszyk również na Twoim głównym sklepie generującym 90% obrotu. Zależność jest bezwzględna: jedna baza danych, jeden proces PHP-FPM, jedno środowisko Redis i OpenSearch. Jeśli podczas wieczornego deploymentu poleci błąd kompilacji dependency injection:
bin/magento setup:di:compile
Compilation was interrupted.
In ClassName.php line 42: Source class "Amasty\..." for "..." cannot be empty.Wszystkie Twoje sklepy w multistore leżą jednocześnie w trybie maintenance mode do momentu wykonania rollbacku.
Koszty licencji, infrastruktury i utrzymania — twarde wyliczenia
Decyzja architektoniczna to przede wszystkim Excel. Porównajmy dwa scenariusze dla 2 sklepów generujących łącznie 50 000 unikalnych wizyt miesięcznie i posiadających 15 000 SKU w katalogu.
Scenariusz A: Jedna instancja Multistore
- Hosting: Dedykowana maszyna (np. AMD EPYC 8-core, 64 GB RAM, NVMe) pod PHP 8.3, MariaDB 10.11, Redis i OpenSearch — ok. 800-1200 PLN netto/mies.
- Licencje modułów: Większość wiodących dostawców (Amasty, Mirasvit, MageWorx) licencjonuje wtyczki na pojedynczą instalację Magento (Single Production Domain/Instance), niezależnie od liczby podpiętych domen. Koszt pakietu modułów (SEO, Hyvä Themes, Allegro, płatności, kurierzy): ok. 2500 - 4000 EUR jednorazowo.
- Utrzymanie i SLA: Jedno środowisko do monitorowania, pojedyncze procedury backupu, mniejsza liczba roboczogodzin na comiesięczne aktualizacje systemowe.
Scenariusz B: Dwie niezależne instalacje
- Hosting: Dwie mniejsze instancje chmurowe lub dwa oddzielne serwery VPS/Dedyki (po 32 GB RAM) — ok. 1400-1800 PLN netto/mies. łącznie.
- Licencje modułów: Podwójny zakup każdej wtyczki komercyjnej (dwa klucze licencyjne, dwa pakiety wsparcia technicznego). Koszt początkowy rośnie do 5000 - 8000 EUR.
- Utrzymanie i SLA: Podwójna liczba środowisk do monitorowania. Wyższy koszt stałego abonamentu agencji programistycznej, ale całkowita niezależność biznesowa i zerowe ryzyko rykoszetu awarii.
Polska specyfika: Allegro, szybkie płatności i logistyka
Prowadząc sprzedaż w Polsce, musisz uwzględnić moduły, które rzadko bywają projektowane z myślą o skomplikowanych konfiguracjach multistore:
- Integratory Allegro (np. Macopedia, TradeWatch, Baselinker): Jeśli korzystasz z zewnętrznego integratora typu Baselinker, multistore nie stanowi problemu, bo routing zamówień odbywa się w chmurze zewnętrznej. Jeśli jednak używasz wtyczki natywnej Magento-Allegro, upewnij się, że obsługuje ona multi-account mapping do różnych Store Views.
- Bramki płatności (Przelewy24, PayU, Autopay, BLIK): Każdy Website w Magento musi mieć możliwość wpisania odrębnego ID punktu płatności (POS ID) oraz klucza CRC, jeśli transakcje mają trafiać na oddzielne subkonta bankowe weryfikowane na białej liście podatników VAT.
- Paczkomaty InPost i Geowidget: Moduł wysyłkowy musi bezkonfliktowo renderować mapę punktów odbioru na różnych domenach bez błędów CORS (Cross-Origin Resource Sharing), co wymaga precyzyjnej konfiguracji nagłówków w Nginx na poziomie
map $http_origin.
Checklista decyzyjna: Co wybrać dla Twojego biznesu?
Zanim podpiszesz umowę na wdrożenie lub zaczniesz migrację, odpowiedz na poniższe pytania:
- Wybierz JEDNĄ INSTANCJĘ (Multistore), jeśli: Produkty pochodzą z tego samego źródła magazynowego, rozliczasz się w ramach jednej spółki (jeden NIP dla KSeF), używasz jednego systemu ERP, a różnice między sklepami sprowadzają się do brandingu, cen walutowych lub podziału B2B/B2C.
- Wybierz OSOBNE INSTALACJE, jeśli: Sklepy należą do różnych podmiotów prawnych, planujesz sprzedaż lub wydzielenie jednej z marek w przyszłości, zespoły marketingowe wymagają niezależnych wdrożeń bez koordynacji release'ów, lub systemy magazynowo-księgowe marek są całkowicie niekompatybilne.
Jeśli stoisz przed wyborem architektury pod nowy sklep lub Twój obecny multistore w Magento zaczyna generować trudne do zdiagnozowania błędy wydajnościowe — napisz do nas. Przeanalizujemy Twój katalog, integracje ERP i dobierzemy rozwiązanie, które nie posypie się przy pierwszym większym piksu sprzedażowym.