Azure Cosmos DB consistency levels explained: strong to eventual

Cosmos DB offers five consistency levels between strong and eventual, set as a default on the account and optionally relaxed per client or request. The choice trades read freshness against latency, availability, read RU cost and RPO.

Level	Guarantee	Read quorum	Write quorum	Typical use
Strong	Linearisable: reads return the latest committed write	Local minority (2 of 4 replicas)	Global majority (every region)	Data that must never be stale; single write region only
Bounded staleness	Reads lag writes by at most K versions or T time	Local minority	Local majority	Near-strong across regions with a single write region
Session (default)	Read-your-writes and write-follows-reads within a session	Single replica, using the session token	Local majority	Most user-centric apps
Consistent prefix	Writes within a transaction are seen together and in order	Single replica	Local majority	Ordering matters, staleness doesn’t
Eventual	No ordering guarantee; reads may go backwards	Single replica	Local majority	Counters such as likes or retweets

Key facts:

Session is the default for new accounts and the most widely used level. Session tokens are partition-bound; the SDK tracks them automatically. If several app instances (for example behind a round-robin load balancer) must read their own writes, the session token has to be passed between them, otherwise reads behave like eventual consistency until that client writes.
Strong and bounded staleness read from two replicas, so reads cost about twice the RUs of the other levels. Write RU cost is the same at every level.
Read consistency applies to a single read within a logical partition.
A client- or request-level override affects only reads made through that SDK client. Writes always replicate according to the account default, so an account set to strong still writes synchronously to every region even when a client reads at session or weaker (those reads then use a single replica).
Accounts with multiple write regions can’t use strong consistency, and strong consistency for regions more than 5,000 miles (8,000 km) apart is blocked by default. Bounded staleness in a multi-write account is described as an anti-pattern.
Minimum bounded staleness values: 10 writes or 5 seconds for a single-region account; 100,000 writes or 300 seconds for multi-region.
After changing the account default, restart the application so SDK clients are recreated with the new default.

In Python, a client-level override is passed when the client is created:

client = CosmosClient(endpoint, credential=credential, consistency_level="Eventual")

Common trap: Using a client or request override to get stronger consistency than the account default - the traditional ConsistencyLevel override can only relax consistency. To strengthen it, change the account default. (The newer ReadConsistencyStrategy, which can strengthen per read, is a preview feature of the .NET and Java SDKs in direct mode only.)

Bounded staleness checks staleness only across regions; in a single-region account it gives the same write guarantees as session or eventual consistency while still doubling read RU cost.

Get the whole book

This note is one section of Ultra Transcenders AI-200: Developing AI Cloud Solutions on Azure, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.

Amazon.co.ukKindle: coming soonPaperback: coming soon

Amazon.comKindle: coming soonPaperback: coming soon

Publishing soon on Amazon in Kindle and paperback editions.

About the book · AI-200 terms in the glossary · All AI-200 study notes

More AI-200 study notes

Service Bus vs Event Grid vs Event Hubs: choosing Azure messaging
How to tell commands, discrete events and telemetry streams apart and pick the right Azure messaging service.
Custom KEDA scale rules in Azure Container Apps
How to define KEDA scalers for queues, topics and other event sources in Container Apps.
Azure Container Apps revisions: single vs multiple revision mode
What creates a new revision, and how single and multiple revision modes change deployments.
pgvector indexes on Azure PostgreSQL: IVFFlat vs HNSW vs DiskANN
Exact search versus approximate IVFFlat, HNSW and DiskANN indexes, and how to tune each for recall and latency.
Cache-aside, write-through and invalidation with Azure Managed Redis
The main Redis caching patterns, how to expire and invalidate entries, and the trade-offs of each.
Azure Functions hosting plans: Flex Consumption, Premium and cold start
How the Functions hosting plans differ in scaling, networking and cold start, and which to choose.
Azure Key Vault access model: RBAC vs access policies
Control plane versus data plane, Azure RBAC versus vault access policies, and the roles apps need.