Cosmos DB Consistency Levels – Complete Guide for DP-900
Why Cosmos DB Consistency Levels Matter
Azure Cosmos DB is a globally distributed, multi-model database service. When data is replicated across multiple regions, a fundamental challenge arises: how fresh and consistent should the data be when read from different replicas? This is the classic trade-off between consistency and availability/performance. Cosmos DB addresses this by offering five well-defined consistency levels, giving you granular control over this trade-off. Understanding these levels is critical for the DP-900 exam because they represent a core differentiator of Cosmos DB and are frequently tested.
What Are Cosmos DB Consistency Levels?
Cosmos DB provides five consistency levels, arranged from strongest to weakest:
1. Strong
2. Bounded Staleness
3. Session (default)
4. Consistent Prefix
5. Eventual
These levels form a spectrum. At one end, Strong consistency guarantees that reads always return the most recent committed write. At the other end, Eventual consistency provides no ordering guarantee but offers the highest availability and lowest latency. Each level provides a precise trade-off between consistency, availability, latency, and throughput.
How Each Consistency Level Works
1. Strong Consistency
- Reads are guaranteed to return the most recent committed version of an item.
- This is linearizable consistency — the gold standard of data consistency.
- Trade-off: Higher latency for reads, lower availability during regional outages, and higher Request Unit (RU) cost.
- Use case: Financial transactions, inventory systems where accuracy is critical.
- Important limitation: Strong consistency is only available within a single region or when using a single-write-region configuration. It is not available for multi-region write accounts.
2. Bounded Staleness
- Reads may lag behind writes by at most K versions (updates) or T time interval, whichever is reached first.
- Within the write region, it behaves like Strong consistency.
- Outside the write region, reads honor the staleness window you configure.
- Trade-off: Slightly less consistent than Strong but offers better availability across regions.
- Use case: Applications that need a predictable consistency guarantee with some tolerance for lag, such as leaderboard applications or collaborative editing with near-real-time requirements.
3. Session Consistency (Default)
- This is the most popular and the default consistency level in Cosmos DB.
- Within a single client session, reads are guaranteed to honor the writes made in that same session (read-your-own-writes, monotonic reads, monotonic writes).
- Outside the session, reads follow eventual consistency behavior.
- Trade-off: Excellent balance between consistency and performance for most applications.
- Use case: User profile applications, shopping carts, social media feeds — any scenario where a single user needs to see their own changes immediately.
4. Consistent Prefix
- Guarantees that reads never see out-of-order writes. If writes occur in the order A, B, C, a reader will see A, then A-B, then A-B-C — never A-C or B-A.
- There is no guarantee on how quickly updates appear, only that they appear in order.
- Trade-off: Lower latency than Bounded Staleness or Strong, but no staleness bound.
- Use case: Social media updates, status feeds, or event logs where order matters but slight delays are acceptable.
5. Eventual Consistency
- Provides no ordering guarantee for reads. Replicas will eventually converge, but a reader may see older data at any point.
- Offers the lowest latency and highest availability of all five levels.
- Lowest RU cost for reads.
- Trade-off: No guarantee of data freshness or ordering.
- Use case: Non-critical data like social media 'like' counts, analytics telemetry, or logging where slight inaccuracies are tolerable.
Key Concepts to Remember
- The consistency levels are set at the Cosmos DB account level but can be relaxed (weakened) on a per-request basis. You cannot strengthen consistency beyond the account-level setting on a per-request basis.
- Moving from Strong to Eventual: consistency decreases, but availability, throughput, and latency improve.
- Session is the default and most commonly used level.
- Strong consistency costs approximately twice the RUs of eventual consistency for reads because it requires confirmation from replicas.
- Cosmos DB's consistency levels are backed by SLAs — this is a key differentiator from many other distributed databases.
Visual Summary of the Spectrum
Strong → Bounded Staleness → Session → Consistent Prefix → Eventual
← Higher Consistency | Higher Availability & Lower Latency →
← Higher RU Cost | Lower RU Cost →
Exam Tips: Answering Questions on Cosmos DB Consistency Levels
1. Memorize the order: Strong, Bounded Staleness, Session, Consistent Prefix, Eventual. Many questions test whether you know the relative position of each level on the spectrum.
2. Know the default: The default consistency level is Session. If a question asks what happens when no specific level is configured, the answer is Session consistency.
3. Understand the trade-offs: Exam questions often describe a scenario and ask which consistency level is appropriate. Remember: if the question emphasizes guaranteed latest data → Strong. If it mentions a user seeing their own updates → Session. If order matters but delay is okay → Consistent Prefix. If maximum performance is needed → Eventual. If a bounded delay is acceptable → Bounded Staleness.
4. Strong consistency limitation: If a question involves multi-region writes, remember that Strong consistency is not supported. This is a common trap.
5. Per-request relaxation: You can weaken the consistency level per request, but you cannot make it stronger than the account default. If a question mentions overriding consistency at the request level, look for answers that only weaken it.
6. RU cost awareness: Strong consistency reads consume more RUs than Eventual. If a question discusses cost optimization for reads, leaning toward weaker consistency levels is the right direction.
7. Scenario matching technique: When faced with a scenario-based question, first identify the key requirement (absolute accuracy, user session experience, ordering, performance, or cost), then map it to the corresponding consistency level.
8. Watch for distractors: Terms like "linearizability" map to Strong. Terms like "read-your-own-writes" map to Session. Terms like "no out-of-order reads" map to Consistent Prefix. Know these keyword-to-level mappings.
9. SLA-backed: Cosmos DB provides SLA-backed consistency guarantees. If a question contrasts Cosmos DB with other databases regarding consistency guarantees, this is a key differentiator.
10. Bounded Staleness configuration: Remember that Bounded Staleness is defined by two parameters: a number of versions (K) and a time interval (T). If a question mentions configuring a lag window, the answer is Bounded Staleness.
By understanding these five levels, their trade-offs, and the common exam patterns described above, you will be well-prepared to answer any DP-900 question on Cosmos DB Consistency Levels with confidence.
