Hyresgäster, värden och datafiltret
ToRun bygger på ABP Frameworks modell för flera hyresgäster. En rad som är markerad med IsMultiTenant har en TenantId-kolumn som ramverket filtrerar på automatiskt; frågor i en hyresgästs kontext ser aldrig en annan hyresgästs rader. Värdkontexten (TenantId == null) ser en separat del: där finns kanoniska kataloger som SubscriptionPlan, AiProvider och LegalDocument.
Varför vi behandlar värden som en fullvärdig deltagare
De flesta SaaS-produkter lägger till värden som "administrationsverktyg". Vi modellerar den som en syskonhyresgäst: värden har egna översiktspaneler, egna AI-policyer och egna faktureringsrelationer. Det låter oss köra vår egen produktionstrafik på samma byggstenar som varje kund använder.
Plankopplade funktioner per hyresgäst
Prenumerationsplaner bär FeatureLimit-, Entitlement-, Capability- och Mode-rader. När en hyresgäst aktiverar en plan är mängden funktioner den kan nå snittet av dess plan och den globala katalogen. Att lägga till ett nytt läge kräver inte att varje hyresgäst ändras: den får läget automatiskt om planen den har innehåller det.
BYOK-injektion vid varje anrop
Även med delad infrastruktur förblir BYOK-uppgifter begränsade till den hyresgäst som äger dem. Varje AI-begäran hämtar uppgifterna i hyresgästens kontext med samma datafilter; nycklar kan inte läcka mellan hyresgäster i lagringslagret.
Vad vi medvetet inte gör
Vi isolerar inte hyresgäster på databas- eller processnivå. Kostnaden för att skala en databas per hyresgäst förstör enhetsekonomin för en SaaS-produkt med flera hyresgäster. Datafiltret tillsammans med en cache som är separerad per hyresgäst räcker när schemat är utformat för det från dag ett.