Hello! Welcome to our first lesson on Azure Cosmos DB. In the previous module, we focused on Azure Blob Storage, finishing with a look at how to manage the data lifecycle to optimize costs. We're now shifting gears to a different, powerful data service designed for high-performance, globally-distributed applications.
This lesson kicks off our module on Cosmos DB by tackling a foundational concept. We will address the learning outcome: Explain the consistency levels in Azure Cosmos DB and when to use each. In any distributed database where data is copied across multiple locations, a fundamental trade-off emerges between data consistency (ensuring every user sees the most up-to-date data) and performance (speed and availability). Cosmos DB uniquely offers a spectrum of choices to manage this trade-off, and understanding them is essential for building robust applications and for success on the AZ-204 exam.
Let's begin by visualizing this core trade-off.
1. An Overview of the Five Consistency Levels
Azure Cosmos DB provides five distinct consistency levels, giving you fine-grained control over your application's behavior. The two ends of the spectrum are Strong consistency, which is similar to the guarantees you might be used to in traditional relational databases, and Eventual consistency, which prioritizes performance above all else. Between these two extremes lie three intermediate options that offer a balance.
To get a quick but comprehensive tour of all five levels and their typical use cases, the following video from the Microsoft Azure team is an excellent starting point.
Consistency | Azure Cosmos DB Essentials Season 1
This video, "Consistency | Azure Cosmos DB Essentials", provides a concise overview of each of the five consistency models, complete with practical examples for when you might choose each one.
Watch the video from the beginning to the discussion on multi-region writes. As you watch, focus on the real-world application described for each level: Eventual: Real-time recommendations Strong: Online auction Consistent Prefix: Group chat Session: Online shopping cart Bounded Staleness: Mobile delivery app
As the video illustrates, your choice of consistency level is not a purely technical decision but one that should be driven by the functional requirements of your application.
2. A Detailed Look at Each Level
Now that you have a high-level understanding, let's delve into the specific guarantees and characteristics of each consistency level. The official Microsoft Learn documentation provides the most precise definitions.
Consistency level choices - Azure Cosmos DB
This official documentation is the definitive guide to Cosmos DB consistency. It details the guarantees for each level.
Please read the following sections to understand the specifics of each model: Start with "Guarantees associated with consistency levels." Read the description for Strong consistency. Read the description for Bounded staleness consistency. Read the description for Session consistency. Pay close attention here, as this is the default and most commonly used level. Note the concepts of "read-your-writes" and the Session Token. Read the description for Consistent prefix consistency. Finally, read the description for Eventual consistency.
To help consolidate this information, here is a summary of the guarantees provided by each level, from strongest to weakest:
| Consistency Level | Guarantees | Common Use Case |
|---|---|---|
| Strong | Linearizability. All reads are guaranteed to return the most recent committed version of an item. Reads across all regions are identical. | Financial systems, auction sites, inventory management. |
| Bounded Staleness | Reads might lag behind writes by a configurable amount of time (T) or number of versions (K). Reads are guaranteed to be in order (prefix-consistent). | Stock tickers, real-time analytics dashboards. |
| Session | Read-your-writes and write-follows-reads within a single client session. Other sessions see eventual consistency. Order is guaranteed within the session. | User-specific applications like shopping carts, user profiles. |
| Consistent Prefix | Reads are guaranteed to return a prefix of all writes, with no gaps. Out-of-order writes are never seen. | Group chats, comment threads, change feeds. |
| Eventual | No ordering guarantee. Replicas will eventually converge over time if there are no new writes. | Social media "likes," retweet counts, analytics. |
As a developer, the Session consistency level is particularly important. It strikes a pragmatic balance: it ensures a specific user sees their own updates immediately (e.g., when they add an item to a cart), which provides a good user experience, while not incurring the high latency costs of Strong consistency across all users globally. This is managed via a Session Token that your application client sends with its requests.
3. Analyzing the Trade-offs: When to Use Each Level
Choosing a consistency level is about balancing the needs of your application across four dimensions: data consistency, application availability, latency, and throughput.
Let's briefly examine how consistency impacts these factors, which is critical for making the right choice for your application and for answering questions on the AZ-204 exam.
Latency and Throughput
The required consistency directly impacts the performance of your database operations.
- Reads: Strong and Bounded Staleness require reading from a quorum of replicas (a local minority of 2 out of 4) to guarantee consistency, which consumes more Request Units (RUs) and results in roughly half the read throughput compared to the other levels. Session, Consistent Prefix, and Eventual can perform reads from a single replica, offering lower latency and higher throughput.
- Writes: For a single-region account, write latency is low and similar for all levels except Strong. For a globally distributed account, Strong consistency requires that a write be replicated and committed to a global majority of regions before it's acknowledged. This can significantly increase write latency, proportional to the round-trip time between the farthest regions. All other levels only require commitment to a local majority within the write region, with asynchronous replication to other regions, resulting in much lower write latency.
Data Durability (RPO)
Your choice also affects your application's Recovery Point Objective (RPO)—the maximum amount of data you can afford to lose in a disaster.
Consistency level choices - Azure Cosmos DB
Let's revisit the Microsoft Learn documentation for a final, crucial point.
Please read the section Consistency levels and data durability. Focus on the table that maps consistency levels to RPO.
As the documentation states:
- Strong consistency provides an RPO of 0, meaning no data loss.
- Bounded Staleness provides an RPO equal to the staleness window you configure (K versions or T seconds).
- Session, Consistent Prefix, and Eventual have a very low RPO (typically < 15 minutes) but it is greater than zero.
For these reasons, you should carefully consider your application's tolerance for stale data and potential data loss before selecting a level. The following is excellent advice to keep in mind for the exam:
Exam Tip: Avoid the most extreme levels (Strong and Eventual) unless your application requirements absolutely demand them. Session consistency is the recommended default for most general-purpose applications as it provides the best balance of consistency guarantees and performance. If you need stronger guarantees than Session, consider Bounded Staleness before jumping to Strong.
Conclusion
In this lesson, we have explored the five consistency levels offered by Azure Cosmos DB. Understanding these levels is not just about memorizing definitions; it's about grasping the fundamental trade-offs between data integrity and application performance in a distributed system.
Here are the key takeaways:
- Azure Cosmos DB offers five consistency levels: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual.
- The choice represents a trade-off between consistency on one hand, and availability, latency, and throughput on the other.
- Strong provides the highest guarantee (linearizability) but at the cost of higher latency and lower availability.
- Eventual provides the best performance but with no ordering guarantees.
- Session is the default and most widely used level, offering a "read-your-writes" guarantee that is ideal for many user-centric applications.
- Your choice of consistency level directly impacts your application's RPO (data durability) in a disaster recovery scenario.
You now have a solid foundation in one of the most important concepts of Cosmos DB. In our next lesson, we will build on this by examining another critical architectural pillar: partitioning. We'll look at how Cosmos DB distributes data to achieve massive scale and how to choose an effective partition key for your data model.