Stai progettando un'applicazione social distribuita a livello globale che memorizza le timeline e i commenti degli utenti come documenti JSON. Gli utenti devono vedere immediatamente le proprie scritture, mentre la latenza tra le regioni deve rimanere bassa. Le scritture sono distribuite uniformemente per utente. Quale design di Cosmos DB dovresti scegliere?

La scelta di Azure Cosmos DB SQL (Core) API con consistenza Session e una chiave di partizione userId è ottimale. La consistenza Session garantisce che l'utente veda immediatamente le proprie scritture (read-your-own-writes), soddisfacendo il requisito primario. La chiave di partizione userId distribuisce uniformemente i dati per utente, migliorando le prestazioni e riducendo la latenza per le query specifiche dell'utente. Le altre opzioni sono meno adatte: Azure Cosmos DB for MongoDB con consistenza Strong e chiave di partizione region introdurrebbe latenza elevata tra le regioni per le scritture, non soddisfacendo il requisito di bassa latenza. Azure Table Storage con consistenza Eventual non garantirebbe la visibilità immediata delle scritture. Azure Cosmos DB SQL (Core) API con consistenza Strong e chiave di partizione timestamp causerebbe latenza elevata per le scritture globali e non distribuirebbe uniformemente i dati per utente. Azure Cosmos DB Gremlin API con Consistent Prefix e chiave di partizione categoryId è più adatto per grafi e non per timeline/commenti, e Consistent Prefix non garantisce read-your-own-writes.