Una partizione che si divide può dimezzare la capacità disponibile sul singolo segmento, anche se il traffico dell’applicazione non è aumentato. È uno dei problemi incontrati da OpenAI mentre portava Habitat, la propria piattaforma di storage online, a servire oltre un miliardo di utenti in quasi 40 regioni.

Non serve gestire 500 petabyte per ritrovarsi nello stesso schema. Una PMI può vederlo con un catalogo WooCommerce, un CRM, un portale clienti o un’automazione AI: la media resta accettabile, ma un cliente molto attivo, un import massivo o una cache scaduta rallentano anche login e checkout. La lezione utile non è copiare Azure Cosmos DB. È progettare il percorso dei dati in modo che un carico secondario non possa fermare quello che genera fatturato.

Il caso OpenAI, ridotto alle decisioni

Habitat nasce come libreria Python collegata a un database e diventa un servizio distribuito che centralizza routing, autorizzazione, cifratura, request shaping e accesso allo storage. Secondo la prima analisi tecnica di OpenAI, la piattaforma gestisce più di 70 milioni di richieste al secondo e oltre 500 petabyte di dati.

La seconda parte del caso descrive un percorso meno lineare di quanto suggeriscano molte architetture disegnate a tavolino. OpenAI parte da un contenitore condiviso, separa alcuni workload in contenitori dedicati per ridurre il blast radius e poi torna a un modello condiviso come impostazione predefinita. Il ritorno è possibile solo dopo aver introdotto controlli sulle chiavi calde, priorità del traffico, capacità di spostare i dati e un modello operativo condiviso con Azure.

Questa sequenza conta più del prodotto scelto. Non esiste una configurazione sempre corretta: condivisione e isolamento risolvono problemi diversi. Il lavoro dell’architettura è rendere misurabile il momento in cui passare dall’una all’altro.

Progetta il dato prima della capacità

1. Misura le chiavi calde, non soltanto la CPU

In Cosmos DB gli elementi con la stessa partition key appartengono alla stessa partizione logica. Più partizioni logiche possono condividere una partizione fisica, che riceve una quota del throughput del contenitore. La documentazione Microsoft sul partizionamento indica un limite massimo di 10.000 RU/s per partizione fisica e raccomanda chiavi ad alta cardinalità capaci di distribuire in modo uniforme dati e richieste.

OpenAI aveva esposto ai client chiavi comuni come user_id e workspace_id. Il problema non era il nome in sé, ma la collisione tra casi d’uso diversi e la concentrazione del carico su poche chiavi. Inoltre, quando una partizione fisica si divide per crescita dello storage, il throughput assegnato viene ripartito fra le partizioni figlie. Nel caso illustrato da OpenAI, 10.000 RU/s diventano 5.000 più 5.000: più spazio, ma meno margine per il segmento caldo.

Per una PMI il controllo minimo è una dashboard per tenant, workspace o cliente, non solo per server. Registra almeno richieste al secondo, p95 e p99, errori di throttling, dimensione dei record e rapporto tra letture puntuali e query ampie. Una media globale può nascondere il cliente che assorbe metà della capacità o la query che attraversa tutte le partizioni.

2. Condividi per default, isola per motivo

Il single-tenant riduce il blast radius e rende chiara la proprietà del dato, ma moltiplica provisioning, monitoraggio e capacità inutilizzata. OpenAI ha visto anche l’effetto opposto: un servizio testato a 1.000 RU/s poteva arrivare al lancio a un milione di RU/s. In un contenitore condiviso molto grande quel salto assorbiva una parte del margine complessivo; in un contenitore dedicato piccolo poteva superare di cento volte la capacità prevista.

La regola pratica è partire da un pool condiviso con limiti per tenant e definire criteri espliciti di isolamento. Sposta un workload quando richiede una diversa residenza del dato, un obiettivo di disponibilità più severo, prestazioni prevedibili o una separazione normativa. Non creare un database per cliente solo perché è più semplice da spiegare: senza automazione del provisioning, trasforma ogni lancio in un esercizio manuale di capacity planning.

Il piano di uscita va previsto prima. Servono identificatori stabili, una procedura di copia verificabile, dual read o shadow read durante la migrazione e rollback. Se il dato non può muoversi, l’isolamento resta una promessa sulla carta.

Proteggi il percorso critico

3. Dai priorità alle richieste che servono l’utente

Un’importazione, una sincronizzazione o un ricalcolo non dovrebbe competere alla pari con autenticazione, checkout o apertura di una pratica. OpenAI ha introdotto hot key throttling e classi di Quality of Service: il traffico offline viene limitato prima delle richieste interattive. È un controllo applicativo, non un semplice aumento di capacità.

In un progetto WordPress o SaaS bastano tre classi: critica per login, pagamento e operazioni utente; interattiva per dashboard e ricerche; batch per import, export, embedding e report. Ogni classe deve avere coda, timeout, concorrenza e budget separati. Se il database rallenta, il batch arretra e il checkout continua.

Questa separazione vale anche per le funzioni AI. Generare una bozza o aggiornare un indice vettoriale può aspettare; validare un ordine o recuperare i permessi no. Nel mio lavoro considero il rate limit un requisito di prodotto: stabilisce chi conserva una risposta utile quando le risorse non bastano.

4. Usa la cache solo con una strategia di invalidazione

Oltre il 90% delle richieste di Habitat è in lettura. OpenAI ha collocato cache Valkey vicino alle regioni in cui vengono elaborate le richieste e usa il Change Data Capture di Cosmos DB per propagare le invalidazioni. Il TTL resta come limite massimo alla staleness, ma non è l’unico meccanismo.

Il motivo è operativo. Un TTL breve riduce i dati obsoleti ma aumenta i cache miss; un TTL lungo migliora l’hit rate ma può mostrare configurazioni vecchie. L’invalidazione esplicita aggiorna più rapidamente, però deve gestire errori parziali, reti tra regioni e ordine degli eventi. La documentazione Microsoft sul change feed chiarisce che l’ordine è garantito per partition key, non globalmente, e che il processore offre checkpoint automatici con semantica at-least-once.

Quindi il consumer deve essere idempotente. Ogni evento porta un identificatore e una versione; elaborarlo due volte non cambia il risultato. Aggiungi una dead letter queue per gli eventi che falliscono in modo permanente e misura il lag fra scrittura e invalidazione. OpenAI riferisce milioni di modifiche catturate al secondo, distribuite su più di cento topic Kafka: il numero impressiona, ma la struttura serve già con cento eventi al minuto.

Se stai valutando costi e colli di bottiglia, collega questa scelta al quadro più ampio descritto in AI: CPU, SSD e memoria cambiano. La cache non cancella il costo dello storage: sposta una parte delle letture e introduce un nuovo stato da osservare.

Prova i guasti reali, non quelli comodi

5. Il failover va testato con dimensioni di produzione

Nel 2024 un’interruzione elettrica nella regione Azure primaria mostrò a OpenAI che il failover degli account più grandi avrebbe richiesto ore. Un mese dopo, durante il ritorno alla regione originale, una massa di nuove connessioni sovraccaricò il gateway. Il database aveva repliche, ma il comportamento combinato di client, gateway, connessioni e partizioni non era stato provato a quella scala.

Una replica non equivale a un piano di continuità. Il test deve includere DNS, pool di connessioni, credenziali, code, cache, webhook e recupero dei processi batch. Misura Recovery Time Objective e Recovery Point Objective con traffico rappresentativo, poi verifica anche il failback: spesso è il passaggio meno provato.

Per una PMI è realistico programmare due esercizi l’anno. Il primo interrompe una dipendenza in un ambiente controllato; il secondo ripristina da backup un campione e confronta conteggi, checksum e permessi. Se un fornitore è critico, il contratto deve prevedere un canale di escalation tecnico e dati esportabili. Come mostra il caso Habitat, a una certa criticità il servizio gestito diventa un servizio co-gestito.

Ottimizza nell’ordine giusto

6. Prima affidabilità, poi latenza, infine costo

OpenAI descrive una sequenza netta: rendere il sistema affidabile per il traffico mission-critical, poi veloce per utenti distribuiti, infine efficiente. Dopo replica selettiva dei dataset più sensibili, cache regionali e riscrittura del proxy in Rust, la latenza mediana globale di lettura è scesa da circa 120 a circa 10 millisecondi, un miglioramento di dodici volte dichiarato dall’azienda.

Non significa che ogni PMI debba riscrivere un servizio in Rust. Il risultato unisce tre interventi: posizionamento dei dati, cache e riduzione dell’overhead del proxy. Se si cambia linguaggio prima di misurare rete e cache miss, si rischia di ottimizzare la parte più visibile ma meno costosa.

Lo stesso principio vale nello stack AI. Prima si definiscono permessi, fallback e osservabilità; poi si lavora su latenza e qualità; solo dopo si riducono token, storage e compute. Ho raccolto una lettura complementare in AI: lo stack conta più del modello: il modello è una dipendenza, mentre il controllo resta nell’architettura.

Un piano operativo in 30 giorni

  1. Settimana 1 — mappa il percorso critico. Elenca le operazioni che generano ricavi o garantiscono accesso. Per ognuna annota database, cache, code, provider esterni, timeout e comportamento in errore.
  2. Settimana 2 — misura per tenant e priorità. Aggiungi p95, p99, throttling, saturazione dei pool, cache hit rate e lag degli eventi. Se non puoi distinguere traffico interattivo e batch, correggi prima la telemetria.
  3. Settimana 3 — limita il blast radius. Applica quote per tenant, concorrenza separata per i job e una coda per il lavoro differibile. Definisci i criteri che giustificano un database o un contenitore dedicato.
  4. Settimana 4 — esegui un test di continuità. Simula l’indisponibilità di una dipendenza, misura RTO e RPO, prova il failback e registra una sola azione correttiva con responsabile e scadenza.

La take-away è semplice: non acquistare capacità per compensare un’architettura che non distingue priorità e tenant. Prima rendi visibili le chiavi calde, poi proteggi il percorso critico, infine automatizza lo spostamento dei dati. È questo che trasforma uno storage “scalabile” in un servizio che può crescere senza portarsi dietro ogni incidente.

Fonti