您正在設計一個全球分佈的社交應用程式，該應用程式將使用者時間軸和評論儲存為 JSON 文件。使用者必須立即看到自己的寫入，同時跨區域延遲必須保持在低水準。寫入是按使用者均勻分佈的。您應該選擇哪種 Cosmos DB 設計？

此設計選擇 Azure Cosmos DB SQL (Core) API 是因為它支援 JSON 文件，符合應用程式儲存格式。使用 Session 一致性可確保使用者在寫入後立即看到自己的資料（讀取自己的寫入），同時提供比 Strong 一致性更低的延遲，適合全球分佈應用程式。將 userId 作為分割區索引鍵，可確保每個使用者的資料均勻分佈在不同邏輯分割區中，避免熱點，提高查詢效率，因為寫入是按使用者均勻分佈的。 其他選項不符合需求： MongoDB API 和 Gremlin API 不如 SQL (Core) API 靈活，且 Gremlin API 適用於圖形資料。 Strong 一致性會增加跨區域延遲，不適合低延遲要求。 Eventual 一致性無法保證使用者立即看到自己的寫入。 將 region 或 timestamp 作為分割區索引鍵可能導致熱點，因為資料分佈不均勻。 Azure Table Storage 不支援 JSON 文件，且一致性模型不符合「讀取自己的寫入」需求。