La scelta tra un motore relazionale open-source gestito e un database NoSQL globale è una decisione ricorrente in AZ-305. Il criterio guida non è “quale è migliore”, ma quale profilo di consistenza, distribuzione e costo soddisfa il requisito con il minimo overhead operativo. Applica sempre i pilastri dell’Azure Well-Architected Framework: Reliability, Performance Efficiency e Cost Optimization dominano queste scelte.

Azure Database for PostgreSQL Flexible Server

Flexible Server è la scelta di default per carichi PostgreSQL: offre controllo su versione, parametri server, finestre di manutenzione e burstable/general purpose/memory-optimized.

  • High availability zone-redundant: crea un replica standby sincrona in una availability zone diversa. Raccomandala quando il requisito è resilienza al guasto di zona con RPO ≈ 0. Ha un costo doppio di compute e richiede una regione con zone. Se le zone non sono disponibili o il budget è vincolato, usa same-zone HA (protegge dal guasto nodo, non dalla zona).
  • Read replica: replica asincrona in lettura, anche cross-region. È la risposta corretta quando il requisito è scalare le letture o servire report/BI vicino agli utenti, non l’HA. Non confondere: una read replica non garantisce failover automatico né RPO zero.
  • Reliability: per un DR cross-region combina HA zone-redundant nella regione primaria con read replica geografica promuovibile.

Se il requisito è “serverless, autoscaling estremo, pay-per-use senza gestire istanze”, valuta invece la modalità di deployment appropriata; ma per compatibilità PostgreSQL piena e controllo, Flexible Server resta la scelta d’esame.

Selezione dell’API di Azure Cosmos DB

Cosmos DB è un database globalmente distribuito con SLA multipli. La prima decisione è l’API, e in genere è irreversibile:

  • API for NoSQL: default per nuove applicazioni; supporto più ricco a change feed, indicizzazione e feature.
  • API for MongoDB / API for Apache Cassandra: scegli per lift-and-shift di applicazioni esistenti che parlano già quei protocolli.
  • API for PostgreSQL (Citus): sharding distribuito relazionale per workload multi-tenant/analytics ad alta scala.
  • API for Table / Gremlin: rispettivamente migrazione da Azure Table Storage e grafi.

Partition key design

La partition key determina la scalabilità. Scegli una chiave con alta cardinalità e distribuzione uniforme di storage e RU/s. L’errore classico è la hot partition: una chiave come country o tenantId con pochi valori concentra il traffico su poche partizioni logiche, saturando il limite di RU/s per partizione. Preferisci userId, deviceId o chiavi sintetiche composite (es. tenantId_yyyyMM) per distribuire il carico.

I cinque livelli di consistency

Dal più forte al più debole: Strong → Bounded Staleness → Session → Consistent Prefix → Eventual.

  • Strong: lettura sempre più recente committata. Impone che le scritture siano confermate globalmente: incompatibile con multi-region write e con alta latenza globale. Costa di più in RU e latenza.
  • Bounded Staleness: ritardo massimo garantito (versioni o tempo); adatto a scenari cross-region che tollerano staleness limitato.
  • Session (default): coerenza per-sessione, ottimo equilibrio; la scelta raccomandata per la maggior parte delle app web/mobile.
  • Consistent Prefix / Eventual: massima disponibilità e minima latenza/costo; ideali per like, telemetria, contatori dove l’ordine finale conta più della freschezza immediata.

Distribuzione multi-region: single vs multi-region write

  • Single-region write (multi-region read): scritture in una regione, letture locali ovunque. Semplice, nessun conflitto. Scegli quando le scritture sono geo-concentrate e serve solo bassa latenza in lettura.
  • Multi-region write (multi-master): scritture locali in ogni regione → latenza di scrittura minima e disponibilità massima, ma introduce conflict resolution (last-write-wins o custom) e preclude consistency Strong. Raccomandala per applicazioni globali write-heavy che tollerano Session/Eventual.

Trade-off consistenza / latenza / costo

È il cuore dell’esame: consistency più forte → più RU/s consumate e latenza maggiore; multi-region → più costo (RU replicate per regione) ma più resilienza e prossimità. Ottimizza i RU/s con autoscale per carichi variabili e provisioned per carichi prevedibili.

Trappole tipiche d’esame

  • Requisito: scalare le letture PostgreSQL geograficamente → read replica cross-region, NON zone-redundant HA (che serve resilienza, non scaling).
  • Requisito: RPO zero e sopravvivere al guasto di una zona → PostgreSQL Flexible Server HA zone-redundant (standby sincrona), non same-zone né read replica.
  • Requisito: app globale write-heavy a bassa latenza → Cosmos DB multi-region write con consistency Session/Eventual; scegliere Strong è la trappola (blocca il multi-master).
  • Requisito: migrare un’app MongoDB esistente senza riscrivere codice → Cosmos DB API for MongoDB, non API for NoSQL.
  • Sintomo: throttling 429 su poche partizioni → hot partition da partition key a bassa cardinalità; ridisegna con chiave sintetica ad alta cardinalità.
  • Requisito: garanzia di staleness massima nota cross-region → Bounded Staleness, non Strong (impossibile con multi-region write) né Eventual (nessuna garanzia).