Question

Difficulty: HardSet Consistency Levels for Azure Cosmos DB

An organization is deploying an inventory tracking application using an Azure Cosmos DB SQL API account. The account is configured with a single write region in East US and a read replica in West US. To group inventory by availability, the container is partitioned using the /availabilityStatus property, which has only three possible values: 'InStock', 'LowStock', and 'OutOfStock'. The application must meet the following requirements:
- Users must always read their own updates immediately, regardless of which regional application instance they connect to.
- The solution must support stateless web client instances without requiring the application layer to manage or pass session tokens between requests.

During load testing, the application encounters frequent request rate limiting (HTTP status code 429) on write operations.

Which default consistency level must you configure for the Cosmos DB account to meet the consistency and session requirements?

  1. StrongAnswer
  2. B
    Session
  3. C
    Eventual
  4. D
    Bounded Staleness

Answer

Strong
Strong consistency is the correct choice because it guarantees that reads always see the most recent write. This satisfies the requirement of immediate read-your-own-writes for stateless web client instances without needing to manage and pass session tokens. Since the Cosmos DB account has a single write region, Strong consistency is fully supported.

Step-by-Step Solution

1
Analyze the requirements for read-your-own-writes guarantees across multiple stateless client connections without session token propagation.
Identify that any consistency level weaker than Strong requires the use and propagation of session tokens to guarantee that a client reads its own writes across different sessions.
Since the application instances are stateless and cannot pass session tokens, Session consistency cannot guarantee read-your-own-writes.
2
Evaluate the remaining consistency options for global read-your-own-writes guarantees.
Strong consistency is the only level that guarantees reads will always return the absolute latest version of the data across all replicas, satisfying the requirement without token sharing.
Bounded Staleness and Eventual consistency allow reads to lag behind writes, meaning clients may see stale data.
3
Address the HTTP 429 write rate-limiting issue.
Recognize that the HTTP 429 error is caused by a hot partition due to the poor choice of the partition key (/availabilityStatus has only three values), which cannot be solved by changing the consistency level.
A high-cardinality partition key is required to distribute the write load evenly across physical partitions.

Key Concept

Azure Cosmos DB Consistency Levels and Session Token Scope
Estimated Time:2m 0s
Rate this question