Azure Cosmos DB è un database distribuito globalmente, multi-modello, pensato per bassa latenza e scalabilità orizzontale. Per l’esame AZ-204 devi saper scegliere l’API corretta, dimensionare il throughput in Request Unit (RU/s) e — soprattutto — progettare una partition key solida.

Le API disponibili e quando scegliere NoSQL

Cosmos DB espone diverse API, e la scelta si fa alla creazione dell’account (non è modificabile dopo):

  • API for NoSQL (ex Core/SQL): l’opzione nativa, con query SQL-like su documenti JSON. È quella con le funzionalità più aggiornate e il supporto SDK migliore.
  • API for MongoDB: compatibilità wire protocol con MongoDB, utile per migrare app esistenti senza riscrivere il data layer.
  • API for Apache Cassandra: per workload wide-column già scritti in CQL.
  • API for Apache Gremlin: grafi con relazioni complesse (social graph, reti).
  • API for Table: upgrade da Azure Table storage con throughput garantito.

Regola pratica per l’esame: se stai sviluppando una nuova applicazione su Azure, preferisci NoSQL, perché offre le feature più recenti (change feed, integrazione con Azure AI Foundry per vector search, SDK .NET/JS più maturi). Le altre API esistono soprattutto per lift-and-shift di soluzioni preesistenti.

Throughput: Request Unit e modelli di provisioning

Ogni operazione (read, write, query) consuma RU: una lettura puntuale di un documento da 1 KB costa circa 1 RU, le scritture e le query costano di più. Devi provisionare RU/s a livello di database (condivise fra i container) o di container (dedicate).

I tre modelli:

  • Manual (standard): fissi un valore di RU/s. Ideale con carico prevedibile e costante. Oltre il limite scattano i 429 (rate limited) con header x-ms-retry-after-ms; l’SDK ritenta automaticamente.
  • Autoscale: fissi un tetto massimo e Cosmos scala fra il 10% e il 100% di quel valore in base al carico. Perfetto per traffico variabile o imprevedibile, così eviti throttling nei picchi senza pagare il massimo sempre.
  • Serverless: paghi solo per RU consumate, senza provisioning. Adatto a carichi intermittenti, dev/test o app con traffico sporadico e a bassa scala.

La scelta della partition key

Cosmos distribuisce i dati in physical partition raggruppando i documenti per logical partition, identificata dal valore della partition key. È la decisione architetturale più importante e non modificabile dopo la creazione del container. Una buona partition key deve avere:

  • Alta cardinalità: molti valori distinti (es. userId, deviceId, tenantId), così i dati si spalmano su tante logical partition.
  • Distribuzione uniforme sia dello storage sia delle richieste (RU): il traffico deve ripartirsi in modo equo nel tempo.
  • Assenza di hot partition: nessun singolo valore deve concentrare la maggior parte di letture/scritture.

Il limite dei 20 GB e le hot partition

Ogni logical partition ha un tetto rigido di 20 GB. Se scegli una chiave a bassa cardinalità (es. country con pochi valori, o status), rischi di superare i 20 GB e saturare le RU di una physical partition, generando 429 anche se il totale provisionato sarebbe sufficiente. Per contenitori molto grandi valuta una synthetic partition key (es. concatenare userId + data) per aumentare cardinalità e uniformità.

Accesso data-plane con RBAC e managed identity

Per l’accesso ai dati preferisci l’Azure Cosmos DB RBAC data-plane con Microsoft Entra ID token e managed identity, anziché le primary/secondary key. Assegni un ruolo di data-plane (built-in Data Reader o Data Contributor) all’identità dell’app: elimini i segreti dal codice, ottieni audit e principio del least privilege. DefaultAzureCredential nell’SDK .NET risolve automaticamente la managed identity in produzione.

Trappole tipiche d’esame

  • Nuova app cloud-native, scelta API → API for NoSQL (feature più recenti); MongoDB/Cassandra solo per migrazioni di app esistenti.
  • Traffico imprevedibile con picchi, evitare throttling senza sovradimensionare → Autoscale, non manual al valore massimo.
  • Partition key candidata country o status (pochi valori) → è la scelta sbagliata: bassa cardinalità → hot partition e limite 20 GB raggiunto. Preferisci una chiave ad alta cardinalità (userId) o synthetic key.
  • Ricevi errori 429 → non aumentare subito le RU: verifica hot partition e lascia agire il retry dell’SDK; il problema è spesso il design della chiave.
  • Accesso ai dati senza segreti nel codice → Entra ID + managed identity con RBAC data-plane, non le account key.