Jedna platforma, wiele witryn: jak działa multi-tenant e-commerce

Prowadzenie jednego sklepu internetowego to rozwiązany problem. Ciekawe inżynieryjnie zaczyna się, gdy jedna firma prowadzi kilka sklepów jednocześnie, każdy z własnym asortymentem, cenami i marką, współdzieląc infrastrukturę pod spodem. To właśnie problem architektury wielodostępnej. Jego rozwiązanie determinuje każdą kolejną decyzję o tym, jak dodawać nowe marki, wchodzić na nowe rynki i rozwijać platformę bez przebudowywania jej od zera.

Co multi-tenancy naprawdę oznacza

Multi-tenancy oznacza, że jedno uruchomione wystąpienie aplikacji obsługuje wielu niezależnych najemców. W handlu elektronicznym każdy najemca to zazwyczaj sklep: odrębna domena, odrębny katalog produktów, odrębne ceny i osobna przestrzeń kont klientów. Kod działający za wszystkimi tymi sklepami pochodzi z tej samej bazy kodu. Baza danych może być współdzielona lub podzielona, ale logika aplikacji nie jest powielana dla każdej marki osobno.

To zasadniczo różni się od utrzymywania osobnych instalacji. Osobna instalacja na każdą markę to osobne wdrożenia, osobne koszty infrastruktury i osobne cykle aktualizacji. Gdy naprawiasz błąd w systemie jednodostępnym, naprawiasz go osobno dla każdej instalacji. W systemie wielodostępnym naprawiasz go raz i każdy najemca korzysta z poprawki natychmiast. Ten efekt kumulacji jest tym, co czyni multi-tenancy atrakcyjnym w skali.

Dlaczego pasuje do operacji wielomarkowych

Dla firmy zarządzającej kilkoma markami ekonomika platformy wielodostępnej zmienia się diametralnie. Uruchomienie nowej marki oznacza skonfigurowanie nowego najemcy, a nie zlecanie nowego projektu technicznego. Badania pokazują, że architektura wielodostępna skraca czas wdrożenia nowego najemcy o 50-70% w porównaniu do oddzielnych instalacji. Integracja z bramką płatności zbudowana dla marki pierwszej działa dla marki piątej bez żadnego dodatkowego programowania. Narzędzia do zarządzania katalogiem, przepływ realizacji zamówień, logika komunikacji z klientami: wszystko to jest już na miejscu.

Korzyści operacyjne są równie istotne. Jeden zespół utrzymuje jedną platformę. Promocje mogą korzystać ze wspólnej infrastruktury, nawet gdy każda marka prowadzi je niezależnie. Analitykę można segmentować według najemcy z możliwością raportowania zbiorczego. A gdy sama platforma wymaga zmian, inwestycja działa na korzyść wszystkich sklepów jednocześnie.

Najtrudniejsze elementy: izolacja, konfiguracja, domeny

Multi-tenancy tworzy obowiązki, których nie ma w systemach jednodostępnych. Najważniejsza jest izolacja danych. Dane należące do jednego najemcy nie mogą być nigdy widoczne dla innego. Każde zapytanie musi być ograniczone do kontekstu właściwego najemcy. To brzmi prosto w teorii, ale wymaga dyscypliny na każdej warstwie stosu. Niezasięgowane zapytanie, wspólny klucz cache bez prefiksu najemcy, plik przesłany bez identyfikatora najemcy: każda z tych rzeczy to potencjalny wyciek danych.

• Każde zapytanie do bazy danych musi domyślnie zawierać filtr najemcy, nie jako uzupełnienie na końcu.
• Klucze pamięci podręcznej muszą zawierać identyfikator najemcy, by dane nie przenikały między sklepami.
• Ścieżki przechowywania plików muszą być przestrzenią nazw najemcy od pierwszego przesłania.
• Routing domen własnych musi ustalać właściwego najemcę przed uruchomieniem jakiejkolwiek logiki biznesowej.
• Konfiguracja na poziomie najemcy musi być oceniana w czasie żądania, a nie podczas startu aplikacji.

Kiedy osobna instalacja jest lepszym wyborem

Multi-tenancy wprowadza złożoność, która jest warta kosztu dopiero od pewnej skali. Jeśli prowadzisz jeden sklep, albo dwa bardzo różne sklepy, które mają niemal nic wspólnego w logice biznesowej, osobne wdrożenia są prostsze w rozumieniu, łatwiejsze w debugowaniu i szybsze do zmiany. Nakład na utrzymanie wspólnej infrastruktury zwraca się, gdy wspólne elementy są realne i istotne, a nie jedynie powierzchowne.

Właściwy moment na budowanie platformy wielodostępnej to posiadanie jasnej mapy drogowej kilku najemców z realnie wspólnymi wymaganiami, zespołu z dyscypliną do egzekwowania izolacji przez całą bazę kodu i zakresu produktu wystarczająco stabilnego, by wspólny rdzeń nie wymagał przebudowy zaraz po wdrożeniu drugiego sklepu. Zbuduj raz i dobrze, a platforma staje się realnym aktywem. Zbuduj przedwcześnie, a większość czasu spędzisz na zarządzaniu złożonością zamiast uruchamiania nowych marek.