Cosmos DB Consistency Levels
Azure Cosmos DB is a globally distributed, multi-model database service. Understanding its consistency models is crucial for designing applications that meet your specific availability and performance requirements.
Understanding Consistency
In a distributed system like Cosmos DB, when you write data, there's a small delay before that data is visible to all subsequent reads. Consistency levels define how up-to-date your data is when you read it from different regions. Cosmos DB offers five well-defined consistency levels:
The Five Consistency Levels
1. Strong Consistency
Strong consistency guarantees that a read is always guaranteed to return the most up-to-date data. Every read operation returns the result of the latest completed write operation. This provides the strongest guarantee but can incur higher latencies and potentially lower availability in a geo-distributed setup.
- Reads: Always return the latest committed write.
- Writes: Can experience higher latency as they need to be replicated and committed across all relevant regions.
- Availability: Can be lower during network partitions or region failures.
2. Bounded Staleness
Bounded staleness offers a trade-off between consistency and availability. It guarantees that your reads will be at most k updates stale or at most t time interval stale, whichever occurs first. This allows you to specify a tolerance for staleness, improving performance over strong consistency.
- Reads: Return data that is at most k versions behind the latest write, or at most t seconds behind.
- Writes: Generally have lower latency than strong consistency.
- Availability: Higher than strong consistency.
You configure the bounds k (number of updates) and t (time interval) when creating your Cosmos DB account.
3. Session Consistency
Session consistency is the default consistency level for Azure Cosmos DB. It provides strong consistency within a single client session. All reads within a session are guaranteed to see the results of writes performed within that same session. However, reads in different sessions or from different regions might see slightly older data.
- Reads: Within a session, all reads see the results of writes from that same session. Across sessions or regions, reads might lag behind.
- Writes: Good performance.
- Availability: High.
This level offers a good balance between performance, availability, and consistency for most common application scenarios.
4. Consistent Prefix
Consistent prefix guarantees that reads are always returned in some order, and that order preserves a prefix of the writes. This means that if you read a sequence of writes, you will never see a write that is not present in the preceding writes in the sequence. It doesn't guarantee that you'll see the *latest* write, but it ensures that the order is logical.
- Reads: Return a prefix of the write history, maintaining order.
- Writes: Good performance.
- Availability: High.
This level is useful when the order of operations is important, but immediate visibility of the absolute latest write isn't critical.
5. Eventual Consistency
Eventual consistency offers the highest availability and lowest latency. In this model, reads might return stale data. However, if no new writes are made to a data item, eventually all reads to that item will return the last updated value. This is the weakest form of consistency.
- Reads: May return stale data.
- Writes: Very low latency.
- Availability: Highest.
This level is suitable for scenarios where read consistency is not critical, such as analytics or logging where eventual consistency is acceptable.
Choosing the Right Consistency Level
The choice of consistency level depends on your application's requirements for data freshness, availability, and performance. Here's a quick comparison:
| Consistency Level | Read Guarantees | Write Latency | Read Latency | Availability |
|---|---|---|---|---|
| Strong | Latest data | Highest | Highest | Lowest |
| Bounded Staleness | Within k updates or t time | Moderate | Moderate | Moderate |
| Session (Default) | Within session, potentially stale across | Low | Low | High |
| Consistent Prefix | Ordered prefix of writes | Low | Low | High |
| Eventual | Potentially stale data | Lowest | Lowest | Highest |
Configuring Consistency Levels
You can set the desired consistency level for your Azure Cosmos DB account when you create it, or modify it later through the Azure portal or using the Azure SDKs and REST APIs.
For example, using the Azure CLI to set the consistency policy:
az cosmosdb update --name --resource-group --consistency-level <Strong|BoundedStaleness|Session|ConsistentPrefix|Eventual>