Inquilinos, host y el filtro de datos
ToRun se basa en el modelo multiinquilino de ABP Framework. Una fila marcada como IsMultiTenant tiene una columna TenantId que el framework filtra automáticamente; las consultas hechas dentro del contexto de un inquilino nunca ven las filas de otro. El contexto del host (TenantId == null) ve una parte distinta: allí viven catálogos canónicos como SubscriptionPlan, AiProvider y LegalDocument.
Por qué tratamos al host como un participante de pleno derecho
La mayoría de los productos SaaS añaden el host como «herramientas de administración». Nosotros lo modelamos como un inquilino hermano: el host tiene sus propios paneles, sus propias políticas de IA y sus propias relaciones de facturación. Así podemos ejecutar nuestro propio tráfico de producción sobre las mismas piezas que usa cada cliente.
Funciones ligadas al plan por inquilino
Los planes de suscripción llevan filas FeatureLimit, Entitlement, Capability y Mode. Cuando un inquilino activa un plan, su conjunto de funciones accesibles es la intersección entre su plan y el catálogo global. Añadir un modo nuevo no obliga a tocar cada inquilino: lo recibe automáticamente cuando el plan que tiene lo incluye.
Inyección de BYOK en cada llamada
Incluso con infraestructura compartida, las credenciales BYOK siguen limitadas al inquilino que las posee. Cada solicitud de IA resuelve las credenciales dentro del contexto del inquilino con el mismo filtro de datos; las fugas de claves entre inquilinos no son posibles en la capa de almacenamiento.
Lo que no hacemos a propósito
No aislamos a los inquilinos a nivel de base de datos ni de proceso. El coste de escalar una base de datos por inquilino destroza la economía unitaria de un producto SaaS multiinquilino. El filtro de datos más el ámbito de caché por inquilino es suficiente cuando el esquema se diseña para ello desde el primer día.