Tenants, de host en het datafilter
ToRun bouwt voort op het multi-tenantmodel van ABP Framework. Een rij met IsMultiTenant heeft een TenantId-kolom waarop het framework automatisch filtert; query's binnen de context van één tenant zien nooit de rijen van een andere. De hostcontext (TenantId == null) ziet een apart deel: daar staan canonieke catalogi zoals SubscriptionPlan, AiProvider en LegalDocument.
Waarom we de host als volwaardige deelnemer behandelen
De meeste SaaS-producten voegen de host toe als "beheertools". Wij modelleren hem als een zustertenant: de host heeft zijn eigen dashboards, zijn eigen AI-beleid en zijn eigen factureringsrelaties. Zo kunnen we ons eigen productieverkeer draaien op dezelfde bouwstenen die elke klant gebruikt.
Functies per tenant gekoppeld aan het abonnement
Abonnementen bevatten FeatureLimit-, Entitlement-, Capability- en Mode-rijen. Wanneer een tenant een abonnement activeert, is de set functies waartoe hij toegang heeft de doorsnede van zijn abonnement en de globale catalogus. Een nieuwe modus toevoegen vraagt niet om elke tenant aan te passen: hij krijgt die automatisch als zijn abonnement die bevat.
BYOK-injectie bij elke aanroep
Ook bij gedeelde infrastructuur blijven BYOK-gegevens beperkt tot de tenant die ze bezit. Elk AI-verzoek haalt de inloggegevens op binnen de tenantcontext met hetzelfde datafilter; sleutels kunnen op de opslaglaag niet tussen tenants weglekken.
Wat we bewust niet doen
We isoleren tenants niet op database- of procesniveau. De kosten van een database per tenant opschalen maken de unit economics van een multi-tenant SaaS-product kapot. Het datafilter plus een cache per tenant volstaat wanneer het schema daar vanaf de eerste dag voor is ontworpen.