Tenanți, host și filtrul de date
ToRun se bazează pe modelul multi-tenant din ABP Framework. Un rând marcat IsMultiTenant are o coloană TenantId pe care framework-ul o filtrează automat; interogările din contextul unui tenant nu văd niciodată rândurile altuia. Contextul host (TenantId == null) vede o felie separată: acolo trăiesc cataloagele canonice precum SubscriptionPlan, AiProvider și LegalDocument.
De ce tratăm host-ul ca pe un participant cu drepturi depline
Majoritatea produselor SaaS adaugă host-ul ca „instrumente de administrare”. Noi îl modelăm ca pe un tenant frate: host-ul are propriile tablouri de bord, propriile politici AI și propriile relații de facturare. Asta ne permite să rulăm propriul trafic de producție pe aceleași componente pe care le folosește fiecare client.
Funcții legate de plan pentru fiecare tenant
Planurile de abonament poartă rânduri FeatureLimit, Entitlement, Capability și Mode. Când un tenant activează un plan, setul de funcții la care are acces este intersecția dintre planul său și catalogul global. Adăugarea unui mod nou nu cere modificarea fiecărui tenant: îl primește automat dacă planul pe care îl are îl include.
Injectarea BYOK la fiecare apel
Chiar și cu infrastructură partajată, credențialele BYOK rămân limitate la tenantul care le deține. Fiecare cerere AI obține credențialele în contextul tenantului, cu același filtru de date; scurgerea cheilor între tenanți nu este posibilă la nivelul stocării.
Ce nu facem în mod intenționat
Nu izolăm tenanții la nivel de bază de date sau de proces. Costul scalării unei baze de date separate pentru fiecare tenant distruge economia unitară a unui produs SaaS multi-tenant. Filtrul de date plus un cache separat pe tenant sunt suficiente atunci când schema este proiectată pentru asta din prima zi.