L'isolamento tra tenant è una riga di config, non una riscrittura.

È la prima decisione architetturale di ogni SaaS e non ha una risposta universale, ma ha dei criteri chiari.

Database condiviso con isolamento logico è la scelta giusta nella grande maggioranza dei casi B2B: costa meno in infrastruttura, rende banali gli aggiornamenti dello schema, permette di aggiungere un cliente in un'operazione di configurazione. Il suo unico punto debole storico è esattamente quello che il modello dichiarativo risolve — il rischio che un percorso dimentichi il filtro.

Un database per tenant ha senso quando esistono requisiti contrattuali o normativi espliciti di separazione fisica, quando i volumi di un singolo cliente sono tali da richiedere risorse dedicate, o quando dovete poter consegnare a un cliente i suoi dati in modo completamente isolato. Ha costi reali: aggiornamenti da propagare, onboarding più oneroso, complessità operativa che cresce linearmente con i clienti.

Poiché in Pwas l'isolamento logico è dichiarato e non scritto a mano, la scelta può essere presa per ragioni di business invece che per paura, e in configurazioni miste — la maggior parte dei clienti in condivisione, i pochi con requisiti particolari separati — la stessa descrizione del dominio serve entrambi gli scenari.

È lo scenario B2B normale, ed è quello dove la differenza si sente di più. Il cliente A ha tre ruoli, il cliente B ne vuole cinque con nomi suoi, il cliente C vuole che un certo campo sia visibile solo a chi ha una certa responsabilità.

Nel modello tradizionale ogni variante di questo tipo è una richiesta di sviluppo, e dopo dieci clienti la gestione dei permessi è il pezzo più intricato del prodotto — quello che nessuno vuole toccare.

Nel modello dichiarativo i ruoli e le visibilità sono dati di configurazione, non codice. Questo permette una cosa che i prodotti SaaS raramente offrono: lasciare che sia il cliente a definire i propri ruoli, entro i limiti che avete stabilito, senza che questo richieda un intervento da parte vostra. Il vostro supporto smette di essere il collo di bottiglia per ogni richiesta di permessi.

Il limite da conoscere: più flessibilità date, più il vostro prodotto deve poter spiegare all'amministratore del cliente cosa sta configurando. La parte difficile non è più tecnica, diventa di progettazione dell'esperienza.

Cambia in meglio, ed è uno dei benefici meno evidenti fino a che non ci si arriva.

Nell'approccio tradizionale l'interfaccia pubblica è un secondo prodotto: ha un proprio livello di autorizzazione, propri controlli, propria superficie di rischio, e va tenuta in sincronia con l'applicazione principale. È anche il punto in cui i problemi di isolamento si manifestano più spesso, perché è la parte più usata da chi non conosce le convenzioni interne.

Quando i permessi sono dichiarati sul dominio, l'interfaccia esposta non ha un proprio livello di autorizzazione: usa lo stesso. Un cliente che chiama con le proprie credenziali vede esattamente ciò che vedrebbe nell'applicazione, né più né meno. Esporre una nuova entità significa dichiarare che è esposta, non riprogettare i controlli.

Resta da progettare tutto il resto di un'interfaccia pubblica seria — limitazione del traffico, versionamento, documentazione, gestione delle chiavi — che sono problemi veri ma non sono problemi di isolamento.

Dipende da dove vi fa male, e la risposta onesta spesso è no.

Se il vostro prodotto è stabile, i permessi non cambiano quasi mai e non state aggiungendo entità in continuazione, il beneficio non giustifica il lavoro. L'isolamento dichiarato dà valore proporzionalmente a quanto spesso il modello cambia.

Ha invece senso valutarlo in tre situazioni ricorrenti. Quando i permessi sono diventati il freno del prodotto: ogni richiesta di un cliente su chi vede cosa diventa sviluppo. Quando avete avuto un incidente di isolamento, o siete arrivati vicino, e sapete che le difese attuali sono procedurali. Quando state per aggiungere un canale — un'interfaccia pubblica, un portale, un agente AI — e vi rendete conto che replicare i controlli su quel canale è un progetto a sé.

Anche in questi casi l'approccio è incrementale: si porta nel modello dichiarativo un dominio alla volta, senza fermare il prodotto. Vale la stessa logica della modernizzazione applicativa, con la stessa raccomandazione di partire da un perimetro ristretto.