Mandanten, Host und der Datenfilter
ToRun basiert auf dem Mandantenmodell des ABP Framework. Eine als IsMultiTenant markierte Zeile hat eine TenantId-Spalte, die das Framework automatisch filtert; Abfragen innerhalb eines Mandantenkontexts sehen nie die Zeilen eines anderen Mandanten. Der Host-Kontext (TenantId == null) sieht einen anderen Ausschnitt — dort liegen kanonische Kataloge wie SubscriptionPlan, AiProvider und LegalDocument.
Warum wir den Host als vollwertigen Teilnehmer behandeln
Die meisten SaaS-Produkte schrauben den Host als „Admin-Werkzeug“ an. Wir modellieren ihn als Geschwister-Mandanten: Der Host hat eigene Dashboards, eigene KI-Richtlinien und eigene Abrechnungsbeziehungen. So können wir unseren eigenen Produktionsverkehr auf denselben Grundbausteinen betreiben, die jeder Kunde nutzt.
Planabhängige Funktionen pro Mandant
Abonnementpläne tragen Zeilen für FeatureLimit, Entitlement, Capability und Mode. Wenn ein Mandant einen Plan aktiviert, ist sein verfügbarer Funktionsumfang die Schnittmenge aus seinem Plan und dem globalen Katalog. Ein neuer Modus erfordert keinen Eingriff bei jedem Mandanten — er steht automatisch zur Verfügung, sobald der Plan, den der Mandant nutzt, ihn enthält.
BYOK-Einspeisung pro Aufruf
Auch bei gemeinsamer Infrastruktur bleiben BYOK-Zugangsdaten auf den Mandanten beschränkt, dem sie gehören. Jede KI-Anfrage löst die Zugangsdaten innerhalb des Mandantenkontexts mit demselben Datenfilter auf; mandantenübergreifende Schlüssellecks sind auf der Speicherebene nicht möglich.
Was wir bewusst nicht tun
Wir isolieren Mandanten nicht auf Datenbank- oder Prozessebene. Die Skalierungskosten einer Datenbank pro Mandant zerstören die Stückkosten eines Multi-Tenant-SaaS-Produkts. Der Datenfilter plus mandantenbezogenes Cache-Scoping reicht aus, wenn das Schema vom ersten Tag an dafür entworfen ist.