Tenant, host e il filtro dei dati
ToRun si basa sul modello multi-tenant di ABP Framework. Una riga contrassegnata come IsMultiTenant ha una colonna TenantId che il framework filtra automaticamente; le query eseguite nel contesto di un tenant non vedono mai le righe di un altro. Il contesto host (TenantId == null) vede una porzione separata: è lì che vivono i cataloghi canonici come SubscriptionPlan, AiProvider e LegalDocument.
Perché trattiamo l'host come un partecipante a pieno titolo
La maggior parte dei prodotti SaaS aggiunge l'host come "strumenti di amministrazione". Noi lo modelliamo come un tenant fratello: l'host ha le sue dashboard, le sue politiche di IA e i suoi rapporti di fatturazione. Questo ci permette di far girare il nostro traffico di produzione sugli stessi componenti che usa ogni cliente.
Funzionalità legate al piano per tenant
I piani di abbonamento portano righe FeatureLimit, Entitlement, Capability e Mode. Quando un tenant attiva un piano, l'insieme delle funzionalità a cui può accedere è l'intersezione tra il suo piano e il catalogo globale. Aggiungere una nuova modalità non richiede di toccare ogni tenant: la riceve automaticamente se il piano che possiede la include.
Iniezione del BYOK a ogni chiamata
Anche con un'infrastruttura condivisa, le credenziali BYOK restano limitate al tenant che le possiede. Ogni richiesta di IA risolve le credenziali nel contesto del tenant con lo stesso filtro dei dati; le fughe di chiavi tra tenant non sono possibili a livello di archiviazione.
Cosa non facciamo di proposito
Non isoliamo i tenant a livello di database o di processo. Il costo di scalare un database per tenant distrugge l'economia unitaria di un prodotto SaaS multi-tenant. Il filtro dei dati unito a una cache separata per tenant è sufficiente quando lo schema è progettato per questo fin dal primo giorno.