Architettura multi-tenant SaaS B2B: decisioni pratiche

Perché le decisioni multi-tenant appartengono alla prima release

Le scorciatoie single-tenant (deploy separato per cliente) sembrano veloci finché non ne operi dieci. Patch di sicurezza, upgrade dipendenze e fix si moltiplicano. Il commerciale promette 'la vostra istanza' e l'engineering eredita una flotta, non un prodotto. Multi-tenant su database condiviso si costruisce in fretta ed è difficile da mettere in sicurezza se i filtri tenant_id non sono coerenti. Una WHERE mancante diventa titolo di giornale. Schema-per-tenant o database-per-tenant alzano complessità di migrazione e pool connessioni ma semplificano il racconto verso enterprise. I buyer B2B fanno domande concrete presto: i dati restano in UE? La filiale A non vede la B? Possiamo esportare tutto se usciamo? L'architettura deve rispondere senza refactor di sei mesi. La discovery sulle regole tenant va in parallelo a come scegliere un contractor per delivery B2B, non dopo il lancio.

• L'isolamento tenant impatta security review e procurement enterprise
• Fatturazione e entitlement richiedono una chiave tenant stabile dal giorno uno
• SSO e SCIM arrivano prima che nelle app consumer
• Il costo operativo scala con il modello di isolamento, non solo con gli utenti

Modelli di isolamento: condiviso, schema-per-tenant, database-per-tenant

Database condiviso con tenant_id su ogni riga è il default per SaaS B2B early stage. Imporre lo scope tenant nel layer di accesso dati, non solo nei controller. Usare row-level security su Postgres come rete di sicurezza, non come controllo primario. I test d'integrazione devono tentare accessi cross-tenant. Schema-per-tenant isola le tabelle per cliente nello stesso cluster. Le migrazioni girano N volte; serve tooling automatizzato. Pool, backup e restore per tenant diventano operazioni ricorrenti. Utile quando il cliente chiede separazione più forte senza fattura infrastruttura separata. Database-per-tenant (o account dedicato su offering managed) calza su settori regolati e deal enterprise grandi. L'onboarding va productizzato: provisioning, secret, monitoring, pipeline migrazione schema. Il costo per tenant idle conta; negoziare minimo contrattuale. L'ibrido è comune a scala: clienti piccoli su pool condiviso, account strategici su stack dedicati. Documentare la promozione: quando un tenant passa a dedicated, come migri i dati, quanto dura il dual-run, come cambiano webhook e API key?

• Condiviso + tenant_id: build più rapida, massima disciplina sulle query
• Schema-per-tenant: isolamento maggiore, operazioni migrazione più pesanti
• Database-per-tenant: enterprise-friendly, serve provisioning automatico
• Tier ibridi: allineare packaging commerciale a confini infrastrutturali reali

Contesto tenant, autenticazione e autorizzazione

Risolvi il tenant da hostname (customer.app.com), prefisso path o claim JWT. Scegli un segnale primario e validalo lato server su ogni richiesta. Non fidarti di header tenant inviati dal client senza legarli al principal autenticato. Gli utenti B2B appartengono ad organizzazioni con team annidati. Modella organizzazione, workspace e ruolo separati dall'account di fatturazione. Un utente può appartenere a più tenant (consulenti, holding): lo switch sessione deve essere esplicito e auditato. SSO via SAML o OIDC è baseline per mid-market ed enterprise. Pianifica più IdP per tenant, rotazione certificati, provisioning just-in-time vs SCIM per offboarding. L'offboarding deve revocare API key e sessioni, non solo cancellare utenti UI. Service account e API key sono tenant a tutti gli effetti. Scope least privilege, rotazione programmata, audit log d'uso per il cliente. Le integrazioni partner devono rispettare confini di integrazione con sistemi esterni così le chiavi non diventano backdoor non dichiarate.

Piani, entitlement e feature flag per tenant

billing account_id deve mappare in modo pulito su tenant_id o su un albero padre-figlio. Conserva gli entitlement come dati (feature abilitate, limiti, add-on), non come check piano hard-coded sparsi in UI. Un piccolo servizio entitlement valutato al boundary API riduce bug del tipo 'piano Enterprise bypassato su un endpoint'. Limiti d'uso (posti, progetti, chiamate API, storage) richiedono hook di metering precoci. Anche con fatturazione manuale al primo anno, analytics prodotto e fair-use enforcement dipendono da contatori per tenant. Feature flag per tenant supportano pilot e rollout graduali. Separa flag 'beta' da entitlement contrattuale. Il commerciale promette feature; l'engineering deve sapere quale tenant ha cosa e quando scade. I contratti custom rompono packaging SaaS puro. L'architettura deve permettere override senza fork di codice: config per tenant, non if (customerX) nella business logic. Documenta override in tool admin leggibili da finance e customer success.

Compliance, residenza dati e aspettative di audit

GDPR, normative di settore e DPA cliente guidano la scelta regione. Se prometti storage solo UE, object storage, backup, log e tooling supporto devono rispettare lo stesso confine. Engineer di supporto che incollano dati tenant in ticket US possono violare residenza. Audit log B2B: chi ha cambiato permessi, esportato dati, collegato integrazioni, impersonato utenti (se consentito). Retention diversa per tenant: alcuni chiedono sette anni, altri cancellazione a churn. Progetta log append-only con API export verso SIEM cliente. Pen test e timeline SOC 2 assumono evidenze di isolamento tenant coerenti. 'Filtriamo nel layer app' è più debole di scope enforced a database più test. Prepara artifact prima che arrivino i questionari security enterprise.

Performance, noisy neighbor e affidabilità

Infrastruttura condivisa significa che l'import di un tenant rallenta la dashboard di un altro. Mitigazioni: rate limit per tenant, fairness nelle code, cap concorrenza job background, rilevamento noisy neighbor su CPU e I/O. Pubblica policy fair-use accettate in signup. Le chiavi cache devono includere tenant_id. Entry cache senza scope tenant fa leakage tra clienti. Stesso discorso per indici search e prefissi storage file. Gli SLA B2B sono contrattuali. L'architettura li supporta con health check per tier tenant, probe sintetici su journey critici e comunicazione incidenti che nomina lo scope ('tenant UE, modulo reporting') non 'disservizio parziale' vago. Disaster recovery: restore backup per tenant su modelli dedicated; point-in-time recovery su modelli condivisi con drill provati. Il commerciale chiede RPO/RTO; l'engineering deve conoscere i numeri reali.

Da prototipo single-tenant a multi-tenancy vera

Se il primo cliente gira su un fork, pianifica convergenza presto. Passi: introdurre tenant_id sulle tabelle core con backfill; centralizzare contesto auth; spostare config su store scoped per tenant; eliminare branch per cliente in CI. Non mantenere codebase parallele per più di un ciclo vendite. Script migrazione dati con idempotenza e report verifica (conteggi righe per tenant, orphan). Esegui shadow read: nuovo stack serve traffico read confrontato al vecchio finché la confidenza è alta. Per prodotti nati dentro una singola enterprise (tool interno che diventa SaaS), vedi strumenti interni custom vs SaaS packaged ed evita di esportare un modello permessi mono-organizzazione che collassa con più clienti.

Lavorare con un contractor sull'architettura multi-tenant

Chiedi ADR scritti: scelta isolamento, risoluzione tenant, modello entitlement, percorso migrazione. Rifiuta 'usiamo Postgres' senza regole di scope. Rivedi test espliciti di denial cross-tenant. Fasi: contesto tenant e auth (2-4 settimane), enforcement data layer e migrazioni (4-8 settimane), entitlement e admin (3-6 settimane), hardening e osservabilità (continuo). Allinea milestone a fasce di budget SaaS realistiche. L'handover include runbook provisioning tenant, migrazione schema per tier e playbook incidenti per bug isolamento. Tratta difetti isolamento come SEV-1 fino a prova contraria.

Prossimi passi

Documenta gerarchia tenant (account, org, utente), target isolamento anno uno e tre, e tre domande enterprise che devi passare in security review. Prototipa scope tenant nel data layer prima di moduli nuovi. Esplora altre risorse, prenota una call breve per rivedere il modello tenancy, o contattami con previsione numero clienti, requisiti compliance e se i prospect più grandi richiedono infrastruttura dedicata.

Domande frequenti