4.6 Azure Cosmos DB Consistency Levels

Azure Cosmos DB Consistency Levels

Quick Answer: Because Cosmos DB replicates data across regions, it lets you choose how fresh reads must be versus how fast they return. It offers five consistency levels, from strongest to weakest: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual. Stronger = fresher reads but higher latency; weaker = lower latency and higher availability. Session is the default.

In a single-region database, consistency is simple — there is one copy. In a globally distributed database, a write in one region takes time to propagate to others, so you must decide what a reader elsewhere is allowed to see. Cosmos DB makes this a tunable knob rather than a fixed property, which is unusual and a favorite DP-900 topic.

The Five Levels (Strongest to Weakest)

The Core Trade-Off

Moving down the list trades freshness for speed, throughput, and availability:

• Strong must confirm the write reached a quorum of replicas before a read can return the latest value, which costs latency and, in a multi-region setup, limits write topology. It also consumes the most RUs for reads.
• Eventual lets any replica answer immediately with whatever it currently has, giving the lowest latency, highest throughput, and highest availability, at the cost of possibly stale or out-of-order reads.
• The middle three are graduated compromises.

A useful mental model: Strong is a single source of truth everyone waits for; Eventual is many copies that drift then catch up; Session sits in between and quietly does the right thing for most apps by guaranteeing you always see your own writes.

Session: Why It Is the Default

Session consistency is the default because it matches what users actually expect from an interactive app: after you post a comment or update your profile, you see the change immediately on subsequent reads in the same session, even if other users see it a moment later. It delivers low latency and high availability while avoiding the confusing experience of not seeing your own change. Unless a workload has a stricter requirement, Session is the right answer on the exam.

Bounded Staleness and Consistent Prefix

• Bounded Staleness lets you say "reads may be at most 5 seconds or 100 versions behind." It is stronger than Session globally and is used when an app needs near-real-time freshness with a guaranteed, bounded maximum lag.
• Consistent Prefix guarantees you never see writes out of order — if writes happened A, B, C, you might see A, or A-B, or A-B-C, but never A-C. It is useful for ordered event streams and comment threads.

Setting and Overriding Consistency

You configure a default consistency level on the Cosmos DB account. Individual read requests can relax to a weaker level than the default (for example, to squeeze out more throughput on a read that tolerates staleness), but they can never strengthen beyond the account default. So if you anticipate ever needing Strong reads, you must set the account default to Strong.

Exam Decision Rules

• "Must always read the absolute latest value" → Strong.
• "Users must see their own writes immediately" → Session (the default).
• "Bounded, predictable maximum lag acceptable" → Bounded Staleness.
• "Order matters but some lag is fine" → Consistent Prefix.
• "Staleness is harmless; maximize speed and availability" → Eventual.

Why Consistency Is a Distributed-Systems Problem

Consistency only becomes a choice because Cosmos DB keeps copies of your data in several regions and on several replicas. When you write to one replica, that change must travel to the others, and propagation is not instantaneous. The CAP theorem says a distributed system facing a network partition must trade Consistency against Availability, and the related PACELC principle adds that even without a partition you trade consistency against Latency. Cosmos DB turns this unavoidable trade-off into five named settings so you can dial in exactly the behavior your application needs rather than accepting one vendor default.

Each Level, Restated With Its Cost

Note the pattern: only Eventual permits reads to appear out of order; the three middle-and-strong levels all preserve write order even when they allow staleness. That single fact resolves many exam questions that hinge on "can a reader see writes in the wrong sequence?"

Multi-Region Writes and Strong Consistency

A critical exam nuance: Strong consistency cannot be combined with multi-region (active-active) writes. To guarantee every reader sees the absolute latest write, Cosmos DB must coordinate a quorum, which is incompatible with letting every region accept writes independently. So an architecture that needs both global active-active writes and the strongest reads is not possible — you choose one. Globally distributed write-local apps therefore typically run at Session or Bounded Staleness, accepting bounded staleness in exchange for low-latency local writes everywhere.

A Concrete Walkthrough

Imagine a write sequence on a counter: 10, then 11, then 12. Under Strong, every region's reader sees 12 immediately. Under Bounded Staleness with a 5-second bound, a remote reader might briefly see 10 or 11 but never a value newer than 12 and never out of order, and the lag can never exceed 5 seconds. Under Session, the client that wrote 12 always reads 12, while another user might still see 11.

Under Consistent Prefix, any reader might see 10 or 10-11 or 10-11-12 but never 10-12 (skipping 11). Under Eventual, a reader could momentarily see any of the values in any order until replicas converge on 12. Walking this single example across all five levels is the most reliable way to lock in the differences for the exam.

Decision Summary

The practical hierarchy for choosing: start at Session (the sensible default for interactive apps), move up to Bounded Staleness or Strong only when correctness demands fresher reads and you can pay the latency, and move down to Consistent Prefix or Eventual when you want maximum speed, throughput, and availability and stale reads cause no harm. Because you can relax per request but never strengthen beyond the account default, set the account default at the strongest level you might ever need.