Architettura multi-tenant: un SaaS per molti clienti

Quando un prodotto SaaS cresce, prima o poi emerge una decisione strutturale: allestiamo un’installazione separata per ogni cliente oppure condividiamo un’unica piattaforma tra tutti? L’architettura multi-tenant risponde a questa domanda permettendo a un singolo sistema di servire molti clienti —i tenant— mentre ciascuno percepisce il proprio spazio come proprio e isolato. È il modello che sostiene la maggior parte del software in abbonamento moderno, e comprenderlo bene evita sia il sovraccosto di duplicare l’infrastruttura sia il rischio di mescolare dati altrui.

Cosa significa multi-tenant

Un tenant è ogni cliente o organizzazione che usa il prodotto. In un’architettura multi-tenant, quell’insieme di clienti condivide la stessa applicazione e, di solito, lo stesso database, mentre uno strato di isolamento garantisce che nessuno veda informazioni che non gli spettano. Rispetto al modello single-tenant —un’istanza dedicata per cliente— l’approccio condiviso riduce drasticamente la superficie da gestire e aggiornare.

L’isolamento può essere ottenuto in vari modi, e vale la pena conoscerli perché condizionano il resto delle decisioni:

• Database condiviso con colonna di tenant: tutte le tabelle includono un identificatore cliente e ogni query lo filtra. L’opzione più efficiente in costo e la più esigente in disciplina.
• Schema per tenant: stesso database, ma ogni cliente ha il proprio schema. Più isolamento, un po’ più di gestione.
• Database per tenant: separazione forte, utile per clienti con requisiti normativi rigorosi, al prezzo di più infrastruttura da mantenere.

Vantaggi di costo e manutenzione

Il motivo per cui questo modello domina è semplice: si gestisce un solo sistema invece di centinaia. Questo ha conseguenze dirette.

• Un deployment, tutti aggiornati: una correzione o una nuova funzionalità raggiunge tutti i clienti insieme, senza campagne di aggiornamento cliente per cliente.
• Uso migliore delle risorse: la capacità è condivisa, così i picchi di alcuni si compensano con la calma di altri invece di sovradimensionare separatamente.
• Onboarding rapido: attivare un nuovo cliente è creare un record, non predisporre un’installazione completa.
• Osservabilità unificata: metriche, log e allarmi vivono in un solo luogo, il che facilita l’individuazione dei problemi prima che si aggravino.

Quel risparmio non è gratis: si paga con un’ingegneria più accurata. Il costo si sposta dall’hardware alla progettazione.

La sfida reale: isolamento e sicurezza

Condividere una piattaforma significa che un difetto di isolamento non colpisce un cliente, ma potenzialmente tutti. Per questo la sicurezza smette di essere uno strato e diventa un principio trasversale.

Nel multi-tenant, l’isolamento non è una funzionalità che si testa una volta: è una proprietà che si difende in ogni query, ogni endpoint e ogni processo in background.

I punti in cui il rigore conta di più:

• Filtraggio per tenant all’origine: l’identificatore cliente deve essere imposto nello strato di accesso ai dati, non affidato alla memoria di ogni query. Un solo WHERE dimenticato è una fuga.
• Autorizzazione coerente: autenticare chi sei non basta; ogni richiesta deve verificare che l’utente appartenga al tenant di cui richiede i dati.
• Isolamento in tutto ciò che è asincrono: code, attività pianificate, cache ed export devono anch’essi rispettare il confine del tenant, non solo le richieste web.
• Vicini rumorosi: un cliente molto attivo non dovrebbe degradare il servizio degli altri; servono limiti e quote.

Test che presumono cattive intenzioni

Il modo più affidabile per sostenere l’isolamento è trattarlo come qualcosa che si verifica in modo automatico e sistematico: test che tentano, deliberatamente, di accedere ai dati di un altro tenant e che devono sempre fallire. Se quel controllo non è automatizzato, l’isolamento dipende dalla memoria di chi programma, e questo non scala.

Quando ha senso (e quando no)

Il multi-tenant brilla quando offri lo stesso prodotto a molti clienti con esigenze simili e vuoi iterare in fretta su una base comune. È il terreno naturale di un CMS di contenuti o di un ecommerce SaaS, dove il valore sta nel migliorare una piattaforma che tutti condividono.

Ci sono però casi in cui conviene orientarsi verso un isolamento più forte o addirittura dedicato: requisiti normativi che impongono la separazione fisica dei dati, clienti con personalizzazioni così profonde da smettere di condividere un prodotto, o accordi di prestazioni che non tollerano alcuna vicinanza. Molte piattaforme mature finiscono in un modello ibrido: multi-tenant per impostazione predefinita e isolamento rafforzato per i pochi casi che lo giustificano.

Come lo affrontiamo in InAI

In InAI costruiamo prodotto con questa architettura come base. Sia il nostro ecommerce SaaS sia il CMS di contenuti con IA nascono multi-tenant, con l’isolamento per cliente inteso come una regola difesa nello strato dati e verificata in modo automatico, non come una promessa. L’obiettivo è semplice e poco glamour: che ogni cliente goda di una piattaforma che migliora per tutti senza che le sue informazioni si incrocino mai con quelle di nessuno.

Non è magia né un’etichetta di marketing. È una decisione ingegneristica con vantaggi chiari e costi reali, e la chiave sta nell’assumersi quei costi con onestà fin dal primo giorno.