This chapter covers Azure Cosmos DB consistency levels, a critical topic for the AZ-204 exam. Understanding these levels is essential for designing globally distributed applications that balance performance, availability, and data freshness. Expect 5-10% of exam questions to touch on consistency models, their trade-offs, and how to configure them in Cosmos DB. By the end of this chapter, you'll be able to select the appropriate consistency level for your application and understand the underlying mechanisms.
Jump to a section
Imagine a library with a central catalog and multiple branch libraries. When you request a book, the librarian checks the central catalog, which is always up-to-date (Strong consistency). But if you are in a hurry, the librarian might let you grab a book from the nearest branch, which might be a few minutes old (Eventual consistency). Now, consider a system where you request a book and the librarian promises to get you the latest copy if you wait a bit (Bounded staleness). Or, you might get a book from any branch, but the librarian ensures you always see the same version for a given session (Session consistency). Finally, you might get a book from the branch that processed your last request, but not necessarily the latest (Consistent prefix). Each consistency level trades off between freshness and speed, much like how you might choose between getting the exact book you want quickly versus waiting for the latest edition.
What Are Consistency Levels and Why Do They Exist?
Azure Cosmos DB is a globally distributed, multi-model database service. When you replicate data across multiple regions, you face the fundamental trade-off between consistency, availability, and latency (the PACELC theorem). Consistency levels define how up-to-date the data is that a read operation returns. Cosmos DB offers five well-defined consistency levels, each providing a different guarantee. The exam expects you to know each level's behavior, performance characteristics, and appropriate use cases.
The Five Consistency Levels
Cosmos DB provides five consistency levels, from strongest to weakest:
Strong: Guarantees that reads always return the most recent write. This is the highest consistency but incurs the highest latency and lowest availability because writes must be acknowledged by all replicas.
Bounded Staleness: Reads are guaranteed to be within a configurable staleness window (either K versions or T time). This offers a trade-off between strong and eventual consistency.
Session: Guarantees monotonic reads, monotonic writes, read-your-writes, and write-follows-reads within a single client session. This is the default consistency level.
Consistent Prefix: Guarantees that reads never see out-of-order writes. If writes happen in a certain order, reads will see them in that order, but there may be gaps (i.e., some writes may not be visible yet).
Eventual: No ordering guarantee. Reads may return any version of the data, and replicas will eventually converge. This offers the lowest latency and highest availability.
How It Works Internally
Cosmos DB uses a replication protocol based on quorums. Each write is replicated to a set of replicas (the write quorum), and each read contacts a set of replicas (the read quorum). The consistency level determines the size of these quorums and the guarantees provided.
Strong: Write quorum = all replicas in the region (or a majority across regions if multi-region writes are enabled). Read quorum = all replicas. This ensures linearizability.
Bounded Staleness: Write quorum = majority of replicas. Read quorum = majority. The staleness bound (K or T) is enforced by the system tracking the version of the last write and delaying reads if necessary.
Session: Write quorum = majority. Read quorum = primary replica (or a subset). The session token is used to ensure read-your-writes and monotonic guarantees.
Consistent Prefix: Write quorum = majority. Read quorum = any replica. The system ensures that the order of writes is preserved across replicas.
Eventual: Write quorum = majority. Read quorum = any replica. No ordering guarantees.
Key Configuration and Defaults
By default, Cosmos DB accounts are configured with Session consistency. You can change the default consistency level at the account level, and override it for individual read requests using request headers. The consistency level cannot be changed for write requests; writes always use the account-level consistency.
Account-level default: Set via Azure portal, CLI, or SDK. Affects all read operations unless overridden.
Request-level override: Use the x-ms-consistency-level header in REST API or the ConsistencyLevel property in SDK. Override is only allowed for read operations.
Session token: For Session consistency, the client must provide a session token in subsequent requests. The SDK manages this automatically.
Configuration Commands
Using Azure CLI to set account-level consistency:
az cosmosdb update --name my-account --resource-group my-rg --default-consistency-level StrongUsing .NET SDK to override consistency for a read:
ItemRequestOptions requestOptions = new ItemRequestOptions
{
ConsistencyLevel = ConsistencyLevel.Eventual
};
ItemResponse<Item> response = await container.ReadItemAsync<Item>("id", new PartitionKey("pk"), requestOptions);Interaction with Multi-Region Writes
If multi-region writes are enabled, Strong consistency is not supported because it would require cross-region coordination that defeats the purpose of multi-region writes. Bounded Staleness is the strongest available level in that scenario. The exam tests this edge case.
Performance Characteristics
Strong: Highest read and write latency. Read availability may be reduced if replicas are down.
Bounded Staleness: Lower latency than Strong, but still higher than weaker levels. Write availability is similar to Strong.
Session: Good balance. Write latency is moderate; read latency is low because reads can be served from the primary replica.
Consistent Prefix: Low latency for both reads and writes.
Eventual: Lowest latency, highest availability.
Impact on SLA
Cosmos DB offers SLAs for consistency, availability, throughput, and latency. Strong and Bounded Staleness have higher latency SLAs (single-digit milliseconds for reads and writes within the same region). Weaker levels have lower latency but higher availability. The exam may ask about SLA implications.
Summary of Guarantees
| Consistency Level | Guarantees | |-------------------|------------| | Strong | Linearizability | | Bounded Staleness | Staleness bound (K or T) | | Session | Read-your-writes, monotonic reads/writes, write-follows-reads | | Consistent Prefix | No out-of-order writes | | Eventual | No guarantees |
Exam Tip
Memorize the five levels in order: Strong, Bounded Staleness, Session, Consistent Prefix, Eventual. Know which level is default (Session). Understand that Strong is not compatible with multi-region writes. Know that Bounded Staleness is the strongest level available with multi-region writes.
Choose Consistency Level
First, determine the required consistency for your application. If you need linearizability, choose Strong. If you can tolerate some staleness, choose Bounded Staleness. For most applications, Session is sufficient and provides good performance. Consistent Prefix is useful for ordered events. Eventual is for non-critical data. Consider the trade-offs: stronger consistency means higher latency and lower availability.
Configure Account Default
Set the default consistency level at the Cosmos DB account level using Azure portal, CLI, or SDK. This applies to all read operations unless overridden per request. For example, using CLI: `az cosmosdb update --name my-account --resource-group my-rg --default-consistency-level Session`. This step is critical because it affects the entire account's behavior.
Override Per Request (Optional)
For specific read operations, you can override the consistency level by setting the `x-ms-consistency-level` header in REST API or the `ConsistencyLevel` property in SDK. This allows you to use a weaker consistency for non-critical reads to reduce latency. For example, in .NET: `requestOptions.ConsistencyLevel = ConsistencyLevel.Eventual;`. Note: override is only allowed for reads, not writes.
Implement Session Token Management
If using Session consistency, the client SDK automatically manages session tokens. The session token is a string that tracks the client's write operations. Include the session token in subsequent requests to ensure read-your-writes and monotonic guarantees. The SDK handles this transparently, but you can also retrieve and set it manually if needed.
Test and Monitor Consistency
After configuration, test your application to ensure consistency guarantees are met. Use Cosmos DB metrics and logs to monitor latency and consistency-related errors. For example, if you see high read latency with Strong consistency, consider switching to Bounded Staleness. Monitor the `Consistency` metric in Azure Monitor to verify the level is applied.
Scenario 1: E-Commerce Product Catalog
A global e-commerce platform uses Cosmos DB to store product details. The product catalog is read-heavy and updated by administrators. For product listings displayed to customers, eventual consistency is acceptable because a few seconds of delay in showing a price change is tolerable. However, for inventory management, the system uses Session consistency to ensure that administrators see their own updates immediately. The account default is set to Session, and read requests from the public website override to Eventual to reduce latency. This configuration balances performance and consistency. Misconfiguration could occur if an administrator accidentally sets the account default to Strong, causing increased latency and potential throttling during peak traffic.
Scenario 2: Financial Transaction Logging
A financial services company uses Cosmos DB to store transaction logs. Regulatory requirements demand strong consistency for transaction records. The account is configured with Strong consistency, and writes are replicated to two regions for disaster recovery. Multi-region writes are disabled because Strong consistency is required. The application experiences higher write latency, but compliance is met. A common mistake is enabling multi-region writes, which would make Strong consistency unavailable, potentially leading to compliance violations.
Scenario 3: Social Media Feed
A social media application stores user posts in Cosmos DB. The feed must show posts in the order they were created (consistent prefix) but can tolerate some delay. The account is configured with Consistent Prefix consistency. This ensures that users see posts in chronological order without gaps. The application uses multi-region writes to allow users from different regions to post with low latency. Consistent Prefix is the strongest level compatible with multi-region writes. If the developer mistakenly chooses Eventual, users might see posts out of order, causing confusion.
What AZ-204 Tests on This Topic
The exam objective 2.1 includes selecting the appropriate consistency level for Cosmos DB. You need to know:
The five consistency levels and their guarantees.
The default consistency level (Session).
Which levels are compatible with multi-region writes (all except Strong).
How to configure consistency at account and request level.
The trade-offs between consistency, latency, and availability.
Common Wrong Answers
Choosing Strong for all scenarios: Candidates often think stronger is always better. The exam tests that Strong has high latency and is not compatible with multi-region writes. Look for scenarios where performance or multi-region writes are needed.
Confusing Bounded Staleness with Session: Both have read-your-writes guarantees? No, Bounded Staleness does not guarantee read-your-writes; it only guarantees staleness bound. Session does guarantee read-your-writes. The exam may ask which level ensures a user sees their own update.
Assuming Eventual is the default: The default is Session, not Eventual. Candidates who overlook this may answer incorrectly.
Thinking consistency can be overridden for writes: Override is only for reads. Writes always use the account default. This is a common trap.
Specific Values and Terms
Default consistency level: Session.
Bounded Staleness parameters: K (number of versions) and T (time interval). Default K=100, T=5 seconds.
Strong consistency: Requires all replicas to acknowledge writes. Not compatible with multi-region writes.
Session token: A string that tracks the client's write operations. Used for Session consistency.
Edge Cases
Multi-region write with Strong: Not allowed. If you enable multi-region writes, Strong is automatically disabled.
Request-level override with weaker consistency: You can override to a weaker level, but not to a stronger level. For example, if account default is Session, you can override to Eventual, but not to Strong.
Consistency level impact on throughput: Strong and Bounded Staleness consume more Request Units (RUs) because they require more replicas to be contacted.
How to Eliminate Wrong Answers
If the question mentions multi-region writes, eliminate Strong.
If the question mentions 'read-your-writes' for a single user, look for Session.
If the question mentions ordering but allows gaps, look for Consistent Prefix.
If the question mentions a configurable staleness window, look for Bounded Staleness.
If the question mentions no guarantees, look for Eventual.
There are five consistency levels: Strong, Bounded Staleness, Session, Consistent Prefix, Eventual.
Session is the default consistency level for Cosmos DB accounts.
Strong consistency is not compatible with multi-region writes.
Consistency level can be overridden per read request, but not per write request.
Bounded Staleness allows configuration of staleness by K (versions) or T (time).
Session consistency guarantees read-your-writes and monotonic reads/writes within a session.
Consistent Prefix ensures writes are seen in order, but may have gaps.
Eventual consistency offers lowest latency and highest availability with no ordering guarantees.
Multi-region writes require a consistency level weaker than Strong; Bounded Staleness is the strongest available.
The session token is used to maintain Session consistency across requests.
These come up on the exam all the time. Here's how to tell them apart.
Strong Consistency
Guarantees linearizability; reads always return the latest write.
Highest read and write latency.
Not compatible with multi-region writes.
Read quorum includes all replicas.
No configurable staleness window.
Bounded Staleness
Guarantees reads are within a configurable staleness bound (K or T).
Lower latency than Strong but higher than weaker levels.
Compatible with multi-region writes (strongest available).
Read quorum is a majority of replicas.
Configurable staleness window (default K=100, T=5 seconds).
Session Consistency
Guarantees read-your-writes, monotonic reads, monotonic writes, write-follows-reads.
Default consistency level.
Requires session token management.
Read quorum is primary replica (or subset).
Good for user-centric applications.
Consistent Prefix
Guarantees that reads never see out-of-order writes.
No read-your-writes guarantee.
No session token needed.
Read quorum is any replica.
Useful for ordered event streams.
Mistake
Strong consistency is always the best choice because it guarantees the most up-to-date data.
Correct
Strong consistency has higher latency and lower availability. It is not suitable for globally distributed applications with multi-region writes. Use weaker levels when performance or availability is more important.
Mistake
Session consistency guarantees that all users see the same data.
Correct
Session consistency guarantees are per client session. Different sessions may see different versions of data. It does not provide global consistency.
Mistake
You can change consistency level for write operations per request.
Correct
Consistency level override is only supported for read operations. Writes always use the account default consistency level.
Mistake
Eventual consistency means data may never converge.
Correct
Eventual consistency guarantees that if no new writes occur, all replicas will eventually converge to the same value. It does guarantee convergence, just not a time bound.
Mistake
Bounded Staleness is the same as Eventual but with a time bound.
Correct
Bounded Staleness provides a strict bound on staleness (either K versions or T time). Eventual has no bound. Bounded Staleness also provides stronger ordering guarantees.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The default consistency level is Session. This means that by default, clients within the same session will see their own writes, and reads are monotonic. You can change the default at the account level or override per request.
No, Strong consistency is not compatible with multi-region writes. If you enable multi-region writes, the strongest available consistency level is Bounded Staleness. This is because Strong would require cross-region coordination that defeats the purpose of low-latency writes.
You can override the consistency level per read request using the `x-ms-consistency-level` header in REST API or the `ConsistencyLevel` property in the SDK. For example, in .NET: `requestOptions.ConsistencyLevel = ConsistencyLevel.Eventual;`. Note that override is only allowed for reads, not writes.
Bounded Staleness provides a strict bound on how stale data can be, either by number of versions (K) or time (T). Eventual consistency has no such bound. Bounded Staleness also guarantees that reads will eventually see writes in order, whereas Eventual does not guarantee order.
No, Session consistency guarantees are per client session. Different sessions may see different versions of data. It ensures that within a single session, the client sees its own writes and monotonic reads, but not global consistency across sessions.
No, you cannot override to a stronger consistency level than the account default. You can only override to a weaker level. For example, if the account default is Session, you can override to Eventual, but not to Strong.
A session token is a string that tracks the client's write operations. It is used with Session consistency to ensure read-your-writes and monotonic guarantees. The client SDK manages the session token automatically, but you can retrieve it and set it manually if needed.
You've just covered Cosmos DB Consistency Levels for Developers — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?