Azure Cosmos DB Consistency Models

The Consistency Spectrum: A Fundamental Trade-off

In any distributed database that replicates data across multiple locations for high availability and low latency, there is an inherent tension between these goals and the guarantee that every read returns the most up-to-date data. This trade-off is often described by the PACELC theorem, an extension of the CAP theorem, which states that in case of a network partition (P), a system must choose between Availability (A) and Consistency (C), and even when the system is running normally (Else), it must trade between Latency (L) and Consistency (C).

Azure Cosmos DB makes this trade-off explicit by offering five well-defined consistency levels. As an architect, your choice determines the fundamental behavior of your application.

A Broader Spectrum than DynamoDB

Before diving into each level, it's helpful to frame this in the context of your familiarity with DynamoDB. DynamoDB provides two options: Strongly Consistent Reads and Eventually Consistent Reads (the default). Cosmos DB expands on this by providing three intermediate levels, giving you more granular control.

The most important of these is Session consistency, which is the default for Cosmos DB accounts. Let's hear a quick take on why this is a significant advantage.

This ability to choose a "good enough" consistency level that isn't the absolute strongest or weakest is a core design feature of Cosmos DB.

A Tour of the Five Consistency Models

To build a strong intuition for each level, we will explore them from weakest to strongest. The following video uses excellent, practical analogies for each model. We will use it as a guide, supplemented with technical details from the official documentation.

Now, let's examine each level.

1. Eventual Consistency

This is the weakest model, offering the highest performance but the fewest guarantees.

• Guarantee: There are no ordering guarantees for reads. With enough time, all replicas will eventually converge. A client may read values that are older than previously read values.
• Analogy: As the video explains, this is perfect for "likes, retweets, or non-threaded comments" where the exact, real-time count is not critical.
• Trade-off: You get the lowest latency, highest read throughput, and highest availability. It's the most "performant" option if your application can tolerate stale and potentially out-of-order data.

2. Consistent Prefix

This level adds a simple but important guarantee: order.

• Guarantee: Reads will never see out-of-order writes. If a set of writes were performed in the order A, B, C, a client might see A, then A, B, and finally A, B, C, but never A, C.
• Analogy: The video's group chat example is perfect. Messages appear in the order they were sent, even if there's a delay in you seeing the latest ones.
• Trade-off: Offers low latency and high throughput, similar to Eventual, but is crucial for scenarios where the sequence of events matters.

3. Session Consistency

This is the default and most widely used level, providing a pragmatic balance for many applications.

• Guarantee: Within a single client session (typically scoped to a user on a specific device), it provides read-your-writes and write-follows-reads guarantees. This means a user will always see the effect of their own writes immediately. For other sessions, it behaves like Consistent Prefix.
• Analogy: The online shopping cart is the classic example. When you add an item to your cart, you expect it to be there when you refresh the page. Session consistency ensures this without incurring the global performance penalty of Strong consistency.
• Trade-off: This is the sweet spot for user-centric applications. It delivers the performance benefits of weaker consistency (high availability, high throughput) while providing a strongly consistent experience for the user interacting with the system.

4. Bounded Staleness

This level allows you to quantify and limit how "stale" your data can be.

• Guarantee: Reads might lag behind writes by at most a configurable amount, defined either by 'K' versions (number of updates) or a time interval 'T'. It also guarantees Consistent Prefix (reads are never out-of-order).
• Analogy: The video's mobile delivery app example is insightful. You need low write latency to accept orders quickly, and write order matters. You can tolerate a small delay in analytics dashboards reflecting those orders, but the delay must be bounded.
• Trade-off: This is for globally distributed applications where you need predictable, low-latency reads with a guarantee that the data is not "too old." It provides stronger guarantees than Session without the high write latency of Strong.

5. Strong Consistency

This is the strongest guarantee, equivalent to linearizability in traditional database theory.

• Guarantee: A read is guaranteed to return the most recent committed version of an item. A client will never see an uncommitted or partial write.
• Analogy: An online auction is the perfect use case. There can be only one winning bid, and all participants must see the same, most recent bid at all times.
• Trade-off: You get the highest level of data correctness. However, this comes at a significant cost:
  • Higher write latency: A write must be replicated and committed to a quorum of replicas in all associated regions before it is acknowledged as successful.
  • Reduced availability: If a network partition prevents replication to all regions, write operations may fail.
  • Incompatible with multi-region writes.

The Architect's Decision Framework: Analyzing the Trade-offs

Now that you understand each level, let's synthesize this into a decision framework based on the key architectural trade-offs. The official Microsoft Learn documentation provides precise details on these trade-offs.

With those details in mind, let's analyze the trade-offs across three critical axes for a principal engineer: Performance, Durability, and Cost.

1. Performance (Latency & Throughput)

Weaker consistency directly translates to better performance.

• Read Throughput: Reads for Session, Consistent Prefix, and Eventual are served from a single replica, consuming 1 Request Unit (RU) for a 1KB item. Reads for Strong and Bounded Staleness must be served from a quorum of replicas (a "minority quorum") to ensure consistency, and therefore consume 2 RUs for the same read. This means for the same provisioned throughput, you get half the read performance with stronger models.
• Write Latency: For all levels except Strong, write latency is low as the write only needs to commit to a local majority of replicas within a single region before being acknowledged. For Strong consistency, the write must commit to a global majority across all regions, making write latency a function of the round-trip time between your two farthest regions.

2. Data Durability (Recovery Point Objective - RPO)

Your choice of consistency level has a direct impact on potential data loss during a region-wide outage. RPO is the maximum period of recent data updates you can tolerate losing.

• Strong Consistency: Offers an RPO of 0. Because every write is synchronously committed to all regions, a regional failover results in no data loss.
• Weaker Levels (Session, Consistent Prefix, Eventual): In a multi-region setup, these have an RPO of < 15 minutes. Because replication to other regions is asynchronous, a catastrophic failure of the primary write region could result in the loss of data written within the last few minutes that hadn't yet been replicated.
• Bounded Staleness: Offers a tunable RPO, defined by your configured K (versions) or T (time).

This is a critical business decision. If zero data loss is an absolute, non-negotiable requirement, Strong consistency is your only option, and you must accept the associated performance trade-offs.

Conclusion

In this lesson, we explored the five consistency models of Azure Cosmos DB, moving beyond the binary choice offered by systems like DynamoDB. This nuanced spectrum empowers you, as an architect, to make precise, application-aware decisions.

Here are the key takeaways for your architectural framework:

• The Spectrum of Choice: Cosmos DB offers five levels—Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual—that represent a trade-off between consistency, availability, latency, and throughput.
• Session is the Sweet Spot: For most user-facing applications, the default Session consistency provides the ideal balance. It gives users a strongly consistent experience (read-your-writes) while maintaining high performance and availability for the overall system.
• Strong is a Significant Commitment: Choosing Strong consistency provides a zero data loss guarantee (RPO=0) but comes with major implications: doubled read RU cost, significantly higher write latency in global setups, and incompatibility with multi-region writes. It should be used only when business requirements absolutely demand it.
• The Choice is an Architectural Pillar: The consistency level you choose is not a minor configuration detail; it's a foundational decision that dictates your application's behavior in terms of performance, cost, and resilience.

In our next lesson, we will build on this understanding of the Cosmos DB engine. We will explore another key architectural choice: selecting the appropriate Azure Cosmos DB API (e.g., NoSQL, MongoDB, PostgreSQL) for a given data model and application requirement. This will show you how the same underlying engine can be used to serve vastly different application needs.