Inquilinos, host e o filtro de dados
O ToRun se apoia no modelo multi-inquilino do ABP Framework. Uma linha marcada como IsMultiTenant tem uma coluna TenantId que o framework filtra automaticamente; as consultas feitas no contexto de um inquilino nunca veem as linhas de outro. O contexto do host (TenantId == null) vê uma fatia separada: é lá que ficam catálogos canônicos como SubscriptionPlan, AiProvider e LegalDocument.
Por que tratamos o host como participante de pleno direito
A maioria dos produtos SaaS acrescenta o host como "ferramentas de administração". Nós o modelamos como um inquilino irmão: o host tem seus próprios painéis, suas próprias políticas de IA e suas próprias relações de cobrança. Assim podemos rodar o nosso próprio tráfego de produção sobre as mesmas peças que todo cliente usa.
Recursos vinculados ao plano por inquilino
Os planos de assinatura carregam linhas FeatureLimit, Entitlement, Capability e Mode. Quando um inquilino ativa um plano, o conjunto de recursos que ele pode acessar é a interseção entre o plano e o catálogo global. Adicionar um modo novo não exige mexer em cada inquilino: ele recebe o modo automaticamente quando o plano que possui o inclui.
Injeção do BYOK em cada chamada
Mesmo com infraestrutura compartilhada, as credenciais BYOK continuam restritas ao inquilino que é dono delas. Cada requisição de IA resolve as credenciais no contexto do inquilino com o mesmo filtro de dados; vazamentos de chaves entre inquilinos não são possíveis na camada de armazenamento.
O que deliberadamente não fazemos
Não isolamos os inquilinos no nível do banco de dados nem do processo. O custo de escalar um banco por inquilino destrói a economia unitária de um produto SaaS multi-inquilino. O filtro de dados somado a um cache separado por inquilino é suficiente quando o esquema é desenhado para isso desde o primeiro dia.