Nucleo multi-tenante

Il nucleo multi-tenante è uno strato di base della piattaforma/prodotto che serve molti clienti (tenanti) indipendenti su risorse condivise, con isolamento garantito, limiti gestiti e customizzazione sicura. Il nucleo ben progettato riduce il TCO, accelera l'onboarding, semplifica le release e garantisce una qualità prevedibile per ogni inquilino.

1) Modello di locatore e limiti di isolamento

Definizioni

Tenant/Org/Account: organizzazione logica con utenti, dati, regole e limiti.
Isolamento: capacità di prevenire l'impatto di un inquilino sui dati, sulle prestazioni e sulla sicurezza di un altro.

Livelli di isolamento

1. Dati: singoli database/diagrammi/tabelle, crittografia «chiave di locazione», filtri «tenant _ id».
2. Calcoli: quote CPU/RAM/IO, pool di worker per tenente o code «ponderate».
3. Rete: segmentazione, endpoint privati/VPN, elenchi di autorizzazioni per affittacamere.
4. Le operazioni sono migrazioni, backap, DR e incidenti con i limiti di esposizione a un solo inquilino.

Pattern multi-genitorialità

Silo (isolamento rigido): singoli cluster/database per tenante. Massima sicurezza, prezzo elevato.
Pool (risorse condivise): infrastruttura condivisa con isolamento logico migliore efficienza, maggiore rischio di noisy neighbor.
Bridge/Hybrid è un piano di gestione comune + selettivo «silo» per i clienti VIP/regolabili.

2) Identificazione e routing delle richieste di locazione

Autorizzazione dell'inquilino

Per dominio: 'https ://{ tenant} .exampl. com`

Percorso: '/t/{ tenant }/... '

Titolo: «X-Tenant-ID», «X-Org» (convalida firma)

Per token, etichette «tenant _ id», «org _ id», «plan», «scopes»

Instradamento

Il gateway L7 (API-gateway/Ingress) estrae «tenant _ id», arricchisce il contesto («plan», limiti, regione), scrive nelle roulotte/login.
I servizi funzionali accettano il contesto di sola lettura; le soluzioni di percorso e di limitazione prendono il gateway/motore di polizia.

3) Dati e schemi: strategie

Opzioni di storage

Shared-schema, row-level: un insieme di tabelle, campo «tenant _ id», RLS (Row-Level Security).
Shared-DB, per-schema: un database, uno schema separato per tenante; equilibrio tra maneggevolezza e isolamento.
Per-DB/cluster: un database/cluster separato per tenante; più costoso, più facile per le richieste sovrane.

Pratiche chiave

Trasmettere «tenant _ id» ovunque e includerlo nelle chiavi/indici composte.
RLS/Criteri di accesso a livello di database + convalida di servizio «doppio lucchetto».
Crittografia: gerarchia delle chiavi (root KMS → key-invelope per tenante → DEK per oggetto).
L'archivio/riscossione e il «diritto all'oblio» sono gestiti da politici a livello di inquilino.

4) Impostazioni, feci e versioni

Configurazioni per tenante

Tabella/archivio «tenant _ config» (piano, quote, flag fich, localizzazione, SLA).
Le priorità delle configure sono il default del piano di del tenente, l'ambiente dell'utente.
Cache le configurazioni con TTL breve e disabilità per evento.

Flag Fic e compatibilità

Attivazione delle funzioni a tratti (per-tenant/per-cohort), disegni canarini.
Versioning API: contratto stabile + adattatori al limite (back/formati forward-compatibili).

5) Limiti, quote e billing

Regole di consumo

Rate limiting: «richiesti/sec» per tenant/route, «token-baquet» con priorità di piano.
Quote: quantità di storage, numero di oggetti, messaggi/min, jobs/ora.
Fairness: «pianificazione ponderata» delle code e isolamento dei worker per VIP.

Billing

I contatori per «tenant _ id» (usage-metriche) gli aggregatori di fattura.
Snapshot usage al limite (idempotenza e protezione contro la perdita di eventi).
Modelli: piano fisso + sovrapprezzo consumption, post-bere/pre-bere, sconti «tiered».

6) Sicurezza e accesso

Autenticazione/autorizzazione

OIDC/SAML con «tenant _ id», «roles», «scopes».
RBAC/ABAC: ruoli a livello di locazione (Owner/Ammin/Reader), attributi di progetto/reparto.
Accesso delegato (servizio-to-service) con token limitati e mTLS.

Limiti di fiducia

Criteri di accettazione query: verifica della firma intestazione, nonce/timestamp, riferimento all'origine.
Segreti e chiavi: rotazione per-tenant, singoli contesti KMS, controllo delle operazioni chiave.
Multi-region & data residency: pinning del tenante alla regione, flussi crocifissi-regionali controllati.

7) Osservazione «per affittacamere»

Traccia e metriche

I tag obbligatori sono «tenant _ id», «plan», «region», «endpoint», «status».
SLI/SLO per tenant: `availability`, `p95 latency`, `error budget`.
Dashboard e alert per segmenti (VIP/regolabili/nuovi).

Logi e verifiche

Registri delle azioni (chi/cosa/dove/dove) con il deposito invariato e il retensing per la politica dell'inquilino.
Pre-aggregazione degli eventi per lo storage a basso costo, ripristino dei dettagli click.

8) Prestazioni e noisy neighbor

Misure anti-rumore

Limiti per code/worker, CPU-shares e proporzioni IO per tenant.
Separazione cache: prefissi di chiavi «tenant: {id}:...», TTL in base ai piani, protezione da «cache stampede».
Indici e piani di query in base alla selettività dì tenant _ id ".

Partenze fredde e pool caldi

Pre-riscaldamento per finestre VIP/picchi.
I pool elastici dei worker in base ai segnali delle metriche (backpressure/scailing automatico).

9) Aggiornamenti e migrazioni senza interruzioni

Strategia

Migrazioni compatibili Backward (expand → migrate → contract).
Migrazioni «per affittuari»: batch con controllo del progresso, «pausa/ritorno» per «tenant _ id».
Semilibertà e migrazioni «canarie» su un sottoinsieme di affittuari.

DR e incidenti

Piano DR con RTO/RPO per tenant; modalità «read-only» parziale senza downtime globale.
Isolamento dell'incidente: «tenant _ id», lo spegnimento dell'inquilino «caldo» non coinvolge gli altri.

10) API e protocolli

REST/gRPC con il contesto obbligatorio dell'inquilino (etichette/intestazioni).
Eventi (event-driven) - Top con «tenant. {id} .event», filtri e ACL per le sottoscrizioni.
Punti di ingresso globali: il gateway L7 valuta il contesto, applica i limiti, crittografa il criterio del tenente PII.

11) Ciclo di vita dell'inquilino

1. Provider: creazione di una voce di locazione, generazione di chiavi/configurazioni, mappatura di una regione.
2. Attivazione: rilascio di un client OIDC/SAML, creazione di ruoli/regole, quote primarie.
3. Utilizzo: monitoraggio, bollo, aggiornamenti di bandiere/piani.
4. Sospend/trottling: congelamento dei dati/esportazione.
5. Rimozione/esportazione: retenschn, boccapiedi regolate, crypto-cancellazione delle chiavi (crypto-shredding).

12) Mini-riferimento architettura (schema verbale)

Edge (API gateway): TLS/mTLS, estrazione «tenant _ id», limiti, controllo.
Controllo Plane: catalogo di affittuari, configi, flag fich, bollo, policy.
Servizi (Data Plane): servizi stateless, code, worker a quote Redis/kv con prefissi per tenante.
Storage: RLS-DATABASE/singoli schemi/Database KMS con chiavi per locatore; Archiviazione degli oggetti con crittografia envelope.
Osservabilità: training/metriche/logi con tag «tenant _ id», alert per piano.
Ammin - Operazioni isolate (migrazioni/backap) in un sottoinsieme di affittuari.

13) Elenco di controllo prima della vendita

Un unico metodo per definire «tenant _ id» al confine e nei servizi.
I criteri RLS/ACL sono stati convalidati con test e «script negativi».
Quote/limiti/billing valgono su carichi reali; Ci sono protezioni contro i billing drop.
Osservabilità e SLO per tenant; alert per VIP/regolabili.
Le migrazioni sono compatibili, ci sono ritiri parziali e battelli parziali.
Script DR con RTO/RPO per tenant e esercitazioni regolari.
Crittografia con chiave di locazione, rotazione e controllo delle chiavi.
Documentazione dei contratti API/eventi e delle regole di versioning.

14) Errori tipici

Migrazioni globali in un solo colpo senza possibilità di fermarsi su un inquilino problematico.
Dipendenza nascosta da «tenant _ id» nella cache/coda di una fuga di dati/intersezione di code.
Miscelazione di contesti (admin-operazione casualmente senza «tenant _ id»).
Nessun doppio lucchetto, solo un controllo di servizio senza RLS nel database.
Un unico limite per l'intero cluster «noisy neighbor» e una violazione dello SLO.
Bollo opaco senza idempotenza e trailer di controllo.

15) Scelta rapida della strategia

Isolamento/regolazione rigorosa: Silo (singoli database/cluster), regione-lock.
Efficienza bilanciata: Shared-DB per schema + RLS, chiavi per tenant.
Traffico real-time elevato: code comuni con quote «ponderate» e worker dedicati per VIP.
Molte customizzazioni: flag fich + adattatori API, memorizzazione di configurazioni per priorità.

Conclusione

Il nucleo multi-tenante è una disciplina dei confini ingegneristici: definizione esplicita di tenant _ id, isolamento rigoroso su tutti i strati, quote controllate e bollino trasparente, più osservabilità e compatibilità di rilascio. Seguire i pattern descritti consente di scalare il prodotto senza sacrificare la sicurezza, la qualità e la velocità di cambiamento per ciascun inquilino.