Budowa wielodostępnego SaaS: Przestrzenie robocze, role, rozliczenia i izolacja

Architektura wielodostępnego SaaS to domyślny wybór dla każdej platformy B2B, która planuje rozwój poza garstkę klientów. Diabeł tkwi jednak w szczegółach: sposób modelowania przestrzeni roboczych, przypisywania ról, struktury rozliczeń i izolacji dzierżawców decyduje o tym, czy platforma będzie skalować się płynnie, czy upadnie pod ciężarem złożoności. W DigiForze budowaliśmy i przebudowywaliśmy te systemy w dziesiątkach produktów SaaS. Oto, czego się nauczyliśmy.

Przestrzenie robocze: Podstawowa jednostka organizacji

Przestrzeń robocza to logiczny kontener grupujący użytkowników, dane i konfigurację dla pojedynczego klienta (lub zespołu w ramach klienta). Widzieliśmy zespoły, które myliły przestrzenie robocze z kontami rozliczeniowymi czy nawet projektami – nie róbcie tego. Utrzymujcie przestrzeń roboczą jako podstawowy zakres dzierżawcy, a inne koncepcje dodawajcie jako warstwy.

Kluczowe decyzje projektowe:

• Hierarchiczna czy płaska? Niektóre platformy potrzebują przestrzeni roboczych w ramach innych przestrzeni (np. przedsiębiorstwo z wieloma działami). Zalecamy dwupoziomową hierarchię: organizacja (jednostka rozliczeniowa) i przestrzeń robocza (jednostka zespołowa). Unikajcie głębszego zagnieżdżania, chyba że jest to absolutnie konieczne – komplikuje dziedziczenie ról i dostęp do danych.
• Unikalne identyfikatory: Używajcie czytelnych dla człowieka slugów (np. acme lub acme-marketing) w adresach URL, ale wewnętrznie zawsze polegajcie na UUID. Slugi mogą się zmieniać; UUID nie powinny.
• Miękkie usuwanie z okresem karencji: Usunięcie przestrzeni roboczej to drastyczna akcja. Zaimplementujcie 30-dniowe miękkie usuwanie, aby użytkownicy mogli odzyskać dane. Natychmiast zatrzymajcie rozliczenia, ale przechowujcie dane do końca okresu karencji.

Gdy nowy użytkownik się rejestruje, zastanów się nad procesem onboardingu. Czy powinien najpierw utworzyć obszar roboczy, czy może eksplorować piaskownicę? Preferujemy prowadzony przepływ, w którym użytkownik tworzy organizację, następnie swój pierwszy obszar roboczy, a następnie od razu otrzymuje monit o zaproszenie współpracowników. Zmniejsza to tarcie i ustawia oczekiwanie, że platforma jest oparta na współpracy.

Częstym błędem jest przypisywanie planów rozliczeniowych bezpośrednio do obszarów roboczych. Zamiast tego przypisz rozliczenia do organizacji, która zawiera jeden lub więcej obszarów roboczych. Pozwala to firmom na otrzymywanie jednej faktury, jednocześnie dając każdemu zespołowi własny obszar roboczy.

Role i uprawnienia: szczegółowe, ale nie za bardzo

Kontrola dostępu oparta na rolach (RBAC) to standard branżowy, ale szczegółowość ma znaczenie. W DigiForge zazwyczaj zaczynamy od trzech wbudowanych ról – Admin, Członek, Obserwator – i pozwalamy na niestandardowe role dla zaawansowanych planów. Rola Admin ma pełną kontrolę nad obszarem roboczym, Członkowie mogą tworzyć i edytować większość zasobów, a Obserwatorzy mogą tylko czytać.

Gdzie robi się trudno, to zakres uprawnień. Uprawnienia powinny być domyślnie ograniczone do obszaru roboczego, ale możesz potrzebować uprawnień na poziomie organizacji (np. zarządzanie rozliczeniami) lub nawet dostępu do odczytu między obszarami roboczymi dla skonsolidowanych raportów. Modeluj uprawnienia jako zestaw par akcja:zasób i przypisz je do ról. Przechowuj przypisania w tabeli łączącej: (workspace_id, user_id, role_id).

Jednym ze sprawdzonych wzorców jest buforowanie roli użytkownika w tokenie sesji (JWT) zamiast odpytywania bazy danych przy każdym żądaniu. Uważaj jednak: jeśli buforujesz role w JWT, musisz mieć mechanizm unieważniania tokenów po zmianie roli (np. krótki czas wygaśnięcia tokena lub lista blokowanych).

Pomyśl też o dziedziczeniu ról: czy administrator organizacji powinien automatycznie mieć uprawnienia administratora we wszystkich obszarach roboczych? Nasza zasada: role organizacyjne wyznaczają górny pułap, ale role w obszarach roboczych mogą być bardziej restrykcyjne. Na przykład administrator organizacji może uzyskać dostęp do dowolnego obszaru roboczego, ale administrator obszaru roboczego nie może uzyskać dostępu do rozliczeń.

Modele rozliczeń i cen: metadane, a nie logika biznesowa

Rozliczenia to miejsce, gdzie wielodostępność staje się realna. Twój model cenowy – za użytkownika, za obszar roboczy, oparty na użyciu lub warstwowy – musi być odzwierciedlony w modelu danych, ale system rozliczeniowy powinien być odseparowany od głównej aplikacji. Użyj zewnętrznego dostawcy rozliczeń (Stripe, Recurly, Chargebee) i przechowuj w bazie danych tylko identyfikator subskrypcji i identyfikator planu.

Zalecamy następujące podejście do bazy danych:

1. Tabela plans definiująca slug planu, cenę oraz flagi funkcji (np. max_users, storage_gb, api_rate_limit).
2. Tabela organizations z kolumnami current_plan_id i billing_provider_subscription_id. Połącz organizacje z przestrzeniami roboczymi za pomocą tabeli łączącej.
3. Tabela features (lub prosta kolumna JSON) przechowująca nadpisania. Na przykład, jeśli klient wynegocjuje niestandardową stawkę, nadpisz cenę planu na poziomie organizacji.

Najtrudniejszą częścią jest ograniczanie dostępu na podstawie planu. Masz dwie opcje: egzekwować limity w aplikacji (sprawdzać max_users przed zaproszeniem) lub za pomocą liczby wierszy w bazie danych i wyzwalaczy. Preferujemy egzekwowanie na poziomie aplikacji, ponieważ generuje lepsze komunikaty błędów dla użytkownika, ale zawsze dodajemy nocne zadanie uzgadniające, które oznacza organizacje przekraczające limity.

Aktualizacje i downgrade planów wymagają ostrożnego podejścia. Gdy klient dokonuje upgrade'u, natychmiast przyznaj dostęp do nowych funkcji, ale proporcjonalnie rozlicz płatność przez dostawcę. W przypadku downgrade'u musisz zdecydować: zablokować dostęp do funkcji przekraczających nowy plan, czy pozwolić na okres karencji? Zalecamy okres karencji trwający do końca bieżącego cyklu rozliczeniowego, po którym egzekwujesz ograniczenia.

Jedna lekcja z okopów: nigdy nie pozwól, aby błędy płatności prowadziły do utraty danych. Jeśli płatność się nie powiedzie, degraduj system z wdziękiem (np. ogranicz operacje zapisu), ale nie usuwaj danych. Twój klient w końcu zapłaci.

Izolacja dzierżawców: współdzielona a silos

Izolacja to najważniejsza decyzja architektoniczna. Standardowy wybór to współdzielona baza danych (jedna baza dla wszystkich dzierżawców, z kolumną tenant_id w każdej tabeli) lub baza danych na dzierżawcę (każdy obszar roboczy otrzymuje własną bazę). Przetestowaliśmy oba podejścia i w większości projektów stosujemy hybrydę.

• Współdzielona z ścisłym RLS: Dobra dla małych i średnich dzierżawców (poniżej 10 tys. użytkowników). Bezpieczeństwo na poziomie wierszy jest wbudowane w Postgres, a my używamy zmiennej sesyjnej (app.tenant_id) do filtrowania każdego zapytania. To najprostsze rozwiązanie w obsłudze i aktualizacji.
• Baza danych na dzierżawcę: Niezbędna, gdy dzierżawcy wymagają ścisłej zgodności (HIPAA, SOC 2, RODO dotyczące lokalizacji danych) lub gdy aplikacja jest intensywna we/wy na dzierżawcę. Koszty operacyjne są realne – migracje schematów muszą być stosowane do setek baz – ale narzędzia takie jak Flyway i zautomatyzowane CI czynią to zarządzalnym.
• Schemat na dzierżawcę: Rozwiązanie pośrednie wykorzystujące osobne schematy w jednej bazie danych. Oferuje większą izolację niż współdzielona tabela, ale mniejsze koszty operacyjne niż pełne bazy. Używamy tego w niższych planach i przenosimy klientów do bazy na dzierżawcę, gdy tego potrzebują.

Niezależnie od strategii izolacji, nigdy nie pozwalaj na bezpośredni dostęp do bazy danych z klienta. Zawsze kieruj przez warstwę API, która wymusza tożsamość dzierżawcy. I na miłość boską, dla dobra zespołu dyżurnego: nigdy, przenigdy nie używaj tenant_id w URL bez walidacji, że uwierzytelniony użytkownik należy do tego dzierżawcy.

Migracja danych między poziomami izolacji to rzeczywistość. Na przykład, gdy dzierżawca przerasta współdzieloną bazę, może być konieczne przeniesienie go do dedykowanej bazy. Zaplanuj to wcześnie: napisz skrypt migracyjny eksportujący i importujący dane, i przetestuj go na danych zbliżonych do produkcyjnych. Powinien być możliwy do uruchomienia bez przestojów, stosując podejście blue-green.

Automatyczne Provisioning: Niech Maszyna to Zrobi

Ręczne uruchamianie nowych tenantów może działać dla pierwszych dziesięciu klientów, ale nie skaluje się. Jak podkreśla niedawny patent ContractorHUB, wdrożenie zero-touch jest kluczowym wyróżnikiem dla wielodostępnego SaaS [1]. Zbudowaliśmy przepływy provisioningowe, które automatyzują wszystko – od tworzenia bazy danych (lub klonowania schematu) po seedowanie domyślnych danych i wysyłanie powitalnych e-maili.

Typowy zautomatyzowany pipeline provisioningowy:

1. Użytkownik rejestruje się, tworzy organizację i wybiera plan.
2. Webhook od dostawcy rozliczeń wyzwala zadanie provisioningowe (np. funkcję serverless lub zadanie Kubernetes).
3. Zadanie tworzy warstwę izolacji tenanta (schemat lub bazę danych), uruchamia początkowe migracje i wypełnia domyślne role oraz ustawienia.
4. Drugie zadanie wysyła e-mail z instrukcjami logowania i kolejnymi krokami.
5. Użytkownik zostaje przekierowany do nowego workspace'a – w pełni funkcjonalnego – w ciągu kilku sekund.

Idempotentność jest tu niezbędna. Jeśli zadanie provisioningowe nie powiedzie się w połowie, musi być bezpieczne do ponowienia. Cały proces owijamy w maszynę stanów z kolumną provisioning_status w wierszu organizacji: pending → creating → active → failed. Nieudane stany trafiają do kolejki dead-letter w celu ręcznej interwencji.

Nie zapomnij o przygotowaniu infrastruktury pomocniczej: rekordów DNS dla domen niestandardowych, rozgrzewaczy pamięci podręcznej CDN, limitów szybkości API na dzierżawcę oraz alertów monitorujących. Zautomatyzuj wszystko, co da się zautomatyzować, ponieważ ręczne kroki zostaną zapomniane pod presją.

Podsumowanie: Podejście wielodzierżawcze

Wielodzierżawność to nie coś, co dodaje się po starcie. Musi ona kierować twoim modelem danych, kontrolą dostępu, integracją rozliczeń i strategią wdrożenia od pierwszego dnia. Dobra wiadomość: jeśli opanujesz te cztery filary – obszary robocze, role, rozliczenia i izolację – reszta twojego SaaS stanie się znacznie łatwiejsza do zbudowania i utrzymania.

Każdy SaaS jest inny, ale powyższe wzorce sprawdziły się w różnych branżach. Niezależnie od tego, czy dopiero zaczynasz budowę MVP, czy skalujesz do tysięcy dzierżawców, zachęcamy do dogłębnego przemyślenia tych decyzji. A jeśli potrzebujesz drugiej pary oczu do oceny swojej architektury, zawsze chętnie pomożemy.