Multi-tenancy nel SaaS: silo, pool o bridge — e il percorso tra i modelli

La decisione più costosa prima del primo cliente

In una piattaforma SaaS, il modello di tenancy è il punto in cui si incrociano unit economics, postura di sicurezza e velocità di sviluppo. Determina quanto costa servire ogni cliente, fino a dove si propaga un incidente, che cosa può promettere con credibilità a un auditor e quanto sarà dolorosa ogni migrazione futura. I team dedicano settimane alla scelta del framework frontend e un pomeriggio al modello di tenancy. Le proporzioni andrebbero invertite: i framework si sostituiscono, i modelli di tenancy si calcificano.

Tre modelli canonici coprono lo spazio — silo, pool e bridge — e nessuno è semplicemente il migliore. Ciascuno scambia isolamento con costi operativi. La domanda utile non è quale modello sia giusto, ma quali compromessi la Sua azienda possa permettersi oggi — e quanto costerà cambiare idea più avanti.

Silo, pool, bridge — i trade-off reali

I modelli differiscono in ciò che condividono e in ciò che dedicano; ogni modalità di guasto discende da questa scelta.

• Silo — ogni tenant riceve risorse dedicate, di norma un database e spesso anche il compute. Isolamento massimo e la storia di conformità più semplice — ma un costo minimo fisso per tenant e un problema di flotta: duecento tenant significano duecento database da migrare, salvare, aggiornare e monitorare.
• Pool — tutti i tenant condividono l'infrastruttura, separati da un tenant_id. Il costo marginale per tenant tende a zero, ma l'isolamento diventa compito dell'applicazione e una sola query scritta male può degradare tutti contemporaneamente.
• Bridge — compute condiviso su dati separati (schema o database per tenant), oppure una flotta a livelli: infrastruttura pooled per il piano standard, silo dedicati per i tenant regolamentati o enterprise.

Per i prodotti B2B il nostro default è un modello pooled dietro una rigorosa astrazione di tenancy, con il silo venduto come livello premium a pagamento, mai adottato per riflesso. Un'infrastruttura dedicata che nessuno paga non è architettura: è un sussidio.

L'isolamento è difesa a livelli, non una clausola WHERE

Una colonna tenant_id più la disciplina degli sviluppatori non è una strategia di isolamento; basta un filtro dimenticato per ritrovarsi a notificare una violazione dei dati. L'isolamento deve reggere anche quando uno sviluppatore sbaglia — va quindi imposto su più livelli indipendenti.

• Risolva il contesto del tenant una sola volta al bordo — sottodominio, token o header — e lo propaghi in ogni richiesta, job ed evento; nulla a valle deve ricavarlo di nuovo.
• Renda le query cross-tenant impossibili da scrivere per sbaglio: repository o query builder che richiedono l'ambito del tenant per costruzione, non per convenzione.
• Attivi la row-level security nel database come rete di sicurezza: un filtro mancante fa fallire la query invece di esporre un intero dataset.
• Cifri i campi regolamentati con chiavi per tenant, così offboarding e richieste di cancellazione diventano operazioni sulle chiavi, non scansioni di tabelle.
• Mantenga una suite di test automatici sugli accessi cross-tenant; ogni fallimento lì è un incidente di sicurezza, non un ticket di bug.

Noisy neighbor: un problema di equità, non di capacità

Nel modello pooled la capacità è condivisa; senza regole esplicite di equità, il tenant più grande detta la latenza di tutti gli altri, e più hardware alza soltanto il tetto di uno scheduler iniquo. Misuri il consumo per tenant dal primo giorno: una manciata di tenant genera la maggior parte del carico, e non si governa ciò che non si attribuisce.

• Applichi rate limit e quote per tenant a livello di API, incorporati nei piani tariffari, così che i limiti siano una leva commerciale, non una scusa.
• Limiti la concorrenza per tenant nelle code in background — l'import massivo di un tenant non deve mai ritardare i webhook di un altro.
• Imposti statement timeout e instradi le query analitiche verso le repliche; il percorso transazionale non è mai il posto per il reporting.
• Su scala di flotta, l'architettura a celle e lo shuffle sharding contengono il raggio d'impatto di sovraccarichi e deployment difettosi.

Una observability che sa dire la parola tenant

La prima domanda in ogni incidente SaaS è: chi è coinvolto? Se la Sua telemetria non risponde in pochi secondi, ha dashboard, non observability. Renda l'identità del tenant una dimensione di prima classe in log, trace e metriche, gestendo la cardinalità in modo deliberato: fedeltà piena in log e trace, top N più aggregati nelle metriche.

Definisca SLO per tenant almeno per il Suo livello più alto e misuri il consumo in modo continuo. Gli stessi dati rispondono alle domande del supporto in pochi minuti, alimentano il pricing a consumo e portano alla luce i clienti che sta silenziosamente servendo in perdita.

Progetti la migrazione prima di averne bisogno

Con qualunque modello parta, prima o poi un tenant dovrà spostarsi: un contratto enterprise esigerà un silo, oppure una flotta di silo diventerà troppo costosa da gestire. Il percorso di migrazione è parte dell'architettura, non un pensiero a posteriori.

• Mantenga il tenant_id su ogni riga anche nei database a silo — consolidare i dati senza è archeologia.
• Tenga gli schemi identici tra i silo; la deriva degli schemi trasforma in silenzio una migrazione in una riscrittura.
• Instradi i tenant attraverso un'astrazione stabile che collega ciascun tenant alla posizione dei suoi dati, così che la posizione possa cambiare senza toccare l'applicazione.
• Provi il trasloco in anticipo: export limitato al tenant, cutover basato su replica, una breve finestra di dual write e un rollback verificato.

Il modello con cui parte non sarà quello con cui finirà. Il compito dell'architettura è rendere quel cambiamento un progetto pianificato, non un'emergenza per l'intera azienda.