Dzierżawcy, host i filtr danych
ToRun opiera się na wielodzierżawnym modelu ABP Framework. Wiersz oznaczony jako IsMultiTenant ma kolumnę TenantId, którą framework automatycznie filtruje; zapytania w kontekście jednego dzierżawcy nigdy nie widzą wierszy innego. Kontekst hosta (TenantId == null) widzi osobny wycinek: to tam żyją kanoniczne katalogi, takie jak SubscriptionPlan, AiProvider i LegalDocument.
Dlaczego traktujemy hosta jak pełnoprawnego uczestnika
Większość produktów SaaS dokłada hosta jako „narzędzia administracyjne”. My modelujemy go jako dzierżawcę siostrzanego: host ma własne pulpity, własne zasady AI i własne relacje rozliczeniowe. Dzięki temu możemy puszczać nasz własny ruch produkcyjny przez te same elementy, z których korzysta każdy klient.
Funkcje przypisane do planu dla każdego dzierżawcy
Plany subskrypcji zawierają wiersze FeatureLimit, Entitlement, Capability i Mode. Gdy dzierżawca aktywuje plan, zbiór dostępnych dla niego funkcji to część wspólna jego planu i globalnego katalogu. Dodanie nowego trybu nie wymaga zmian u każdego dzierżawcy: dostaje go automatycznie, jeśli jego plan go obejmuje.
Wstrzykiwanie BYOK przy każdym wywołaniu
Nawet przy wspólnej infrastrukturze dane uwierzytelniające BYOK pozostają ograniczone do dzierżawcy, który je posiada. Każde żądanie AI pobiera dane uwierzytelniające w kontekście dzierżawcy przez ten sam filtr danych; wyciek kluczy między dzierżawcami nie jest możliwy w warstwie przechowywania.
Czego celowo nie robimy
Nie izolujemy dzierżawców na poziomie bazy danych ani procesu. Koszt skalowania osobnej bazy dla każdego dzierżawcy niszczy ekonomię jednostkową wielodzierżawnego produktu SaaS. Filtr danych wraz z pamięcią podręczną rozdzieloną per dzierżawca wystarcza, gdy schemat jest od pierwszego dnia do tego zaprojektowany.