Semantic search

ARCHITECTURE.md

@@ -888,44 +888,6 @@ END $$;
 
 ## 4. Decisioni Architetturali
 
----
-
-### ADR-001 – Multi-tenancy: Schema-per-tenant vs Row-level con tenant_id
-
-**Opzione A – Schema-per-tenant (un PostgreSQL schema per ogni organizzazione)**
-
-*Pro:*
-- Isolamento totale dei dati: impossibile data leak cross-tenant per bug SQL
-- Backup e restore per singolo tenant molto semplici
-- Possibilità di migrare un tenant su un DB separato senza refactoring
-
-*Contro:*
-- Alembic migrations vanno applicate a tutti gli schema (N schema × migrazione)
-- Connection pooling complesso: PgBouncer deve gestire schema switching
-- Difficile fare query aggregate cross-tenant (es. monitoraggio globale SaaS)
-- Overhead operativo significativo oltre i 100 tenant
-
-**Opzione B – Row-level con `tenant_id` + PostgreSQL RLS**
-
-*Pro:*
-- Un solo schema, migrations applicate una volta
-- Query cross-tenant per operazioni di sistema (monitoring, billing)
-- Molto più semplice da gestire con Alembic e ORM
-- Scala bene fino a decine di migliaia di tenant
-
-*Contro:*
-- Bug nell'impostazione `current_tenant_id` può causare data leak → mitigato con RLS come secondo livello
-- Restore di singolo tenant richiede WHERE clause su dump
-
-**Raccomandazione: Opzione B (row-level + RLS)**
-
-Per un SaaS B2B con caselle PEC, il numero di tenant nel medio termine è nell'ordine delle centinaia, non decine di migliaia. Il rischio principale (data leak cross-tenant) è mitigato da due strati indipendenti:
-1. Applicativo: ogni query include `WHERE tenant_id = :current_tenant_id`
-2. DB: PostgreSQL RLS come safety net, impostata tramite `SET LOCAL app.current_tenant_id = '...'` in ogni transazione
-
-Il vantaggio operativo (migrazioni semplici, query di monitoring, pool unico) supera i rischi, a condizione di avere test di integrazione che verificano il corretto isolamento.
-
----
 
 ### ADR-002 – Cifratura credenziali IMAP/SMTP a riposo