Consistency Levels: Five Choices, Real Trade-Offs

The consistency spectrum

Simple explanation

Think of a news broadcast. Strong consistency is a live broadcast — everyone sees the same thing at the same time, but there’s a slight delay. Eventual consistency is a newspaper — fast to print, but different readers might get different editions for a while.

Cosmos DB gives you five points on this spectrum. More consistency = higher latency and cost. Less consistency = faster and cheaper, but readers might see stale data temporarily.

Jake’s consistency dilemma

🛒 Jake at GlobeCart has replicated his product catalogue to three regions. But now he faces questions:

When a seller updates a price in East US, how quickly must customers in Europe see it?
When a customer adds an item to their cart, must the next read reflect it immediately?
Is it OK if product reviews appear slightly delayed across regions?

Each answer points to a different consistency level. Let’s explore all five.

The five levels

1. Strong consistency

Guarantee: Every read returns the most recent committed write. Linearizable — as if there’s a single copy of the data.

Analogy: A live video call — everyone sees the same thing at the same millisecond.

Latency: Highest read latency (waits for quorum across regions)
RU cost: 2× the RU cost of a standard read
Restriction: ⚠️ Not available with multi-region writes
Use case: Financial transactions, inventory counts where stale reads cause real-world harm

2. Bounded staleness

Guarantee: Reads may lag behind writes by at most K operations or T seconds, whichever is reached first.

Analogy: A sports ticker with a guaranteed maximum delay — you might be 5 seconds behind live, but never more.

Configuration: You set K (version count) and T (time interval)
Multi-region minimum: K ≥ 100,000 operations AND T ≥ 300 seconds
Single-region minimum: K ≥ 10 operations AND T ≥ 5 seconds
RU cost: 2× the RU cost for reads (same as strong)
Restriction: ⚠️ Not available with multi-region writes
Use case: Leaderboards, analytics dashboards where “near-real-time” is acceptable

3. Session consistency (DEFAULT)

Guarantee: Within a single client session, reads always reflect that session’s own writes (read-your-own-writes). Other sessions may see older data.

Analogy: Your own notepad — you always see what you just wrote, but your colleague’s notepad might not be updated yet.

Latency: Low — no cross-region coordination for your own session
RU cost: Standard (1×)
Why it’s the default: Most applications need “I see what I just wrote” without caring about other users’ sessions
Use case: Shopping carts, user profiles, most CRUD applications

4. Consistent prefix

Guarantee: Reads never see out-of-order writes. If writes happen as A → B → C, reads see A, A→B, or A→B→C — never A→C skipping B.

Analogy: Watching a TV show — you might be behind, but episodes always play in order.

Latency: Low
RU cost: Standard (1×)
Use case: Social media feeds, event logs, chat message history

5. Eventual consistency

Guarantee: Reads will eventually return the most recent write, but there’s no bound on when. Reads may be out of order.

Analogy: A newspaper — eventually everyone gets the news, but different readers see different editions at different times.

Latency: Lowest
RU cost: Lowest (slightly less than session for reads)
Use case: Like counts, view counters, telemetry, non-critical metrics

Comparison at a glance

Level	Guarantee	Read RU Cost	Latency	Multi-Region Writes?
Strong	Linearizable — latest write always	2×	Highest	❌ No
Bounded Staleness	Within K ops or T seconds	2×	High	❌ No
Session (DEFAULT)	Read-your-own-writes per session	1×	Low	✅ Yes
Consistent Prefix	No out-of-order reads	1×	Low	✅ Yes
Eventual	No guarantees on freshness/order	1×	Lowest	✅ Yes

Exam tip: consistency per-request relaxation

The account-level default consistency can be relaxed (weakened) on a per-request basis using SDK headers. You can go from Strong → Bounded Staleness → Session → Consistent Prefix → Eventual.

You cannot strengthen consistency per-request. If the account is set to Session, you cannot request Strong on individual reads. This is a favourite exam question — know the direction of relaxation.

Bounded staleness deep dive

Multi-region bounded staleness minimums:
  K ≥ 100,000 operations
  T ≥ 300 seconds (5 minutes)

Single-region bounded staleness minimums:
  K ≥ 10 operations
  T ≥ 5 seconds

Why the multi-region minimum is high: Cross-region replication has inherent latency. Setting K=10 across continents would cause constant consistency violations. The minimums ensure the staleness window is realistic.

// Bounded staleness is configured at the account level:
// az cosmosdb update --name globecart-cosmos \
//   --default-consistency-level BoundedStaleness \
//   --max-staleness-prefix 100000 \
//   --max-interval 300

Exam tip: the 2× read cost trap

Both Strong and Bounded Staleness cost 2× RU for reads because they require quorum confirmation from multiple replicas. Session, Consistent Prefix, and Eventual all cost 1× because reads go to a single replica.

Exam questions often ask about “cost-effective” consistency — if the scenario doesn’t require strong guarantees, Session is almost always the right answer (and it’s the default).

Per-request consistency in code

// Account default: Session
// Relax to Eventual for a non-critical read
ItemRequestOptions options = new ItemRequestOptions
{
    ConsistencyLevel = ConsistencyLevel.Eventual
};

ItemResponse<Product> response = await container.ReadItemAsync<Product>(
    id: "product-123",
    partitionKey: new PartitionKey("electronics"),
    requestOptions: options
);

Sophie’s pro tip: 🗄️ Sophie, Jake’s DBA, uses Session consistency for the shopping cart (customers must see their own changes) but relaxes to Eventual for product review counts (a few seconds of staleness is fine and saves RU cost).