Tenanti, host a datový filtr
ToRun stojí na multi-tenant modelu ABP Framework. Řádek označený jako IsMultiTenant má sloupec TenantId, podle kterého framework automaticky filtruje; dotazy v kontextu jednoho tenanta nikdy nevidí řádky jiného. Kontext hostitele (TenantId == null) vidí samostatný výsek: tam žijí kanonické katalogy jako SubscriptionPlan, AiProvider a LegalDocument.
Proč bereme hostitele jako plnohodnotného účastníka
Většina SaaS produktů přidává hostitele jako „administrátorské nástroje“. My ho modelujeme jako sesterského tenanta: hostitel má vlastní přehledy, vlastní zásady AI a vlastní fakturační vztahy. Díky tomu můžeme vlastní produkční provoz provozovat na stejných stavebních blocích, které používá každý zákazník.
Funkce vázané na plán pro každého tenanta
Předplatitelské plány nesou řádky FeatureLimit, Entitlement, Capability a Mode. Když tenant aktivuje plán, sada funkcí, ke kterým má přístup, je průnikem jeho plánu a globálního katalogu. Přidání nového režimu nevyžaduje zásah u každého tenanta: dostane ho automaticky, pokud ho jeho plán zahrnuje.
Vkládání BYOK při každém volání
I při sdílené infrastruktuře zůstávají přihlašovací údaje BYOK omezené na tenanta, který je vlastní. Každý požadavek na AI načítá přihlašovací údaje v kontextu tenanta přes stejný datový filtr; únik klíčů mezi tenanty není na úrovni úložiště možný.
Co záměrně neděláme
Tenanty neizolujeme na úrovni databáze ani procesu. Náklady na škálování samostatné databáze pro každého tenanta zničí jednotkovou ekonomiku multi-tenant SaaS produktu. Datový filtr spolu s mezipamětí oddělenou pro každého tenanta stačí, když je na to schéma navrženo od prvního dne.