Carrier HUB è progettato fin dal primo giorno per supportare carichi di lavoro mission-critical nel settore delle telecomunicazioni. Una delle sfide principali per un sistema B2B SaaS dedicato ai carrier telefonici è garantire l'isolamento dei dati, le performance elevate e la compliance normativa in scenari multi-brand (Multi-tenant).

La nostra scelta architetturale fondamentale risiede nell'utilizzo di PostgreSQL 17 abbinato a un rigoroso pattern di isolamento tenant tramite Row-Level Security (RLS).

Perché PostgreSQL 17?

Nel panorama dei database relazionali, PostgreSQL si distingue per robustezza, estensibilità e aderenza agli standard SQL. Con la versione 17, Carrier HUB sfrutta funzionalità avanzate che ci permettono di gestire centinaia di milioni di Call Detail Records (CDR) mensili senza colli di bottiglia:

  • Ottimizzazioni per JSONB: I nostri parser dei file carrier normalizzano formati destrutturati (CSV, XML, JSON) e li immagazzinano in campi JSONB indicizzati. Le operazioni sui JSON in PG17 sono fulminee e ci permettono di mantenere la flessibilità dello schema pur mantenendo la garanzia ACID.
  • Partizionamento Nativo: Il traffico telefonico viene partizionato automaticamente su base mensile. Le query analitiche e gli export ERP pescano solo dalla partizione corretta, ignorando terabyte di storico, garantendo tempi di esportazione misurabili in secondi o minuti (non ore).
  • Parallel Query Execution: Durante le operazioni di ricalcolo massivo delle fatture, PostgreSQL sfrutta i core del nostro cluster per elaborare le query di aggregazione in parallelo.

Architettura Multi-tenant e Row-Level Security (RLS)

In Carrier HUB, un singolo database ospita dati di più tenant (MSP o Brand), ma nessun tenant può accidentalmente leggere i dati di un altro. Come lo garantiamo in modo inattaccabile?

Non ci affidiamo esclusivamente ai controlli logici nell'OR (SQLAlchemy). Se uno sviluppatore commettesse un errore dimenticando un filtro WHERE tenant_id = X, avremmo una violazione dei dati (data leak).

Per impedirlo, usiamo la Row-Level Security (RLS) di PostgreSQL:

  1. Il Contesto della Connessione: Ogni volta che FastAPI apre una sessione con il DB, imposta una variabile di contesto a livello di transazione SQL (es: SET LOCAL carrierhub.current_tenant_id = '123').
  2. Le Policy del Database: Ogni tabella critica (es. clients, cdrs, invoices) ha una policy che impone al motore del database di filtrare in modo invisibile tutte le righe che non corrispondono al current_tenant_id.
  3. Isolamento Deterministico: Se la variabile di contesto non è impostata, il DB restituisce un set vuoto. Nessun dato viene mai restituito se il contesto non è esplicitamente dichiarato.

Questo approccio Defense in Depth è ciò che permette a Carrier HUB di offrire livelli di sicurezza Enterprise-Grade a tutti i nostri clienti.

Conclusioni

Costruire una piattaforma telco affidabile richiede fondamenta solide. La combinazione di PostgreSQL 17, RLS, partizionamento avanzato e un'architettura software pensata per la scalabilità orizzontale ci permette di offrire SLA di uptime fino al 99.99% per il piano Enterprise.

Sei curioso di vedere come Carrier HUB elabora i file carrier in tempo reale? Richiedi una Demo.