# Consistency level

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/consistency-level

## Quick definition

When you store data in the cloud, it is often copied to multiple servers for safety and fast access. Consistency level is a setting that lets you choose between getting the very latest data immediately or getting a slightly older copy faster. It balances speed and accuracy based on what your application needs.

## Simple meaning

Imagine you are part of a group of friends sharing a group chat on a messaging app. One friend sends a message saying, "I am moving the meeting to 3 PM." If the app has strong consistency, every other friend sees that new time at exactly the same moment, no matter which device they check. If the app uses weaker consistency, one friend might still see the old time for a few seconds until the app catches up. In cloud databases, the same idea applies. A consistency level is a rule that tells the database system how strictly it must keep all copies of data in sync before it shows you an answer. 

 For example, if you run an online store and a customer buys the last item in stock, you absolutely need the inventory count to be correct everywhere so no one else buys the same item. That requires strict consistency. But if you are just viewing a product description that changes rarely, you might accept a slightly older copy because it loads faster. Consistency levels give you control over this trade-off. Cloud providers like Microsoft Azure offer several consistency levels for databases like Cosmos DB. Each level has a different balance of performance, availability, and accuracy. Understanding these levels helps you build applications that are both fast and reliable.

## Technical definition

In distributed database systems, data is replicated across multiple nodes or regions to ensure high availability, fault tolerance, and low latency. The consistency level defines the behavior of read and write operations concerning how up-to-date the data must be across all replicas before a read request is considered complete. This is formalized by the PACELC theorem, which builds on the CAP theorem by stating that in a distributed system, if a partition occurs (P), you must choose between availability (A) and consistency (C); otherwise, even without partitions, you must choose between latency (L) and consistency (C). Consistency levels are the practical implementation of these trade-offs. 

 Azure Cosmos DB, a key Azure data service, offers five well-defined consistency levels: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual. Strong consistency guarantees that a read operation returns the most recent write across all replicas, ensuring linearizability. This comes at the cost of higher latency and reduced write availability because all replicas must acknowledge the write before it is committed. Bounded Staleness allows reads to be slightly behind writes by a defined number of versions (K) or a time interval (T), whichever is reached first. This provides a predictable upper bound on data staleness, balancing consistency with performance. 

 Session consistency provides monotonic reads, monotonic writes, read-your-writes, and write-follows-read guarantees within a single client session. This is extremely useful for user-centric applications where a user expects to see their own updates immediately. Consistent prefix ensures that reads never see a version of data that is out of order. For example, if updates happen in sequence A then B, a read will always see A before B, never B without A. Eventual consistency, the weakest level, offers no ordering guarantees. Given enough time, all replicas will converge to the same value, but reads may return stale or out-of-order data. Each consistency level has specific implementation details, including how many replicas must respond, how write acknowledgments are handled, and how conflict resolution is managed. In an IT implementation, selecting the right consistency level involves analyzing application requirements, latency budgets, and compliance needs. For instance, financial transactions often require Strong consistency, while social media feeds can tolerate Eventual consistency.

## Real-life example

Think about a large library with multiple floors, each floor having a copy of the same popular book. A librarian named Pat updates the book by adding a new chapter. If the library uses strong consistency, Pat locks every floor, pastes the new chapter into every copy of the book, and only then tells visitors that the book is ready. Everyone who checks the book immediately sees the new chapter. This process takes time, and while Pat is updating, other visitors cannot borrow the book. 

 Now imagine a library with session consistency. Pat updates the book on the first floor. Visitors on the first floor instantly see the new chapter. A visitor who checked the book on the second floor earlier continues to see the old version for a little while, but if that visitor walks up to the first floor and checks again, they see the new chapter. The library ensures that within a single visitor's experience, they never go back to an older version after seeing a newer one. 

 For a library with eventual consistency, Pat updates the book on the main floor and then gradually sends the new chapter to other floors. A visitor on the third floor might see the old version for several minutes. Eventually, all floors have the new chapter, but there is no guarantee of when. This approach makes the book available to borrow quickly after the update, but some visitors might get outdated information for a short time. This is fine for a book that is rarely changed, like a dictionary of common words.

## Why it matters

In real IT systems, consistency level directly affects user experience, data integrity, and system cost. For an e-commerce platform, if a customer adds an item to their cart but the inventory system shows the item as still available due to weak consistency, another customer might also add it, leading to overselling. This creates customer frustration and operational headaches. On the other hand, enforcing strong consistency on every single database operation would slow down the entire application, making pages load slowly and potentially driving users away. 

 Consistency levels also impact application design and development effort. Developers must understand which consistency guarantees their application actually needs at every point. For example, a banking application needs strong consistency for account balances, but it can use eventual consistency for a list of nearby ATMs. Misunderstanding these needs can lead to data corruption, lost transactions, or unreasonably high latency. 

cloud costs are affected. Strong consistency requires all replicas to be synchronized, which consumes more network bandwidth and increases write latency. Weaker consistency levels reduce this overhead, allowing the database to handle more requests per second at lower cost. Database administrators and cloud architects regularly review consistency level settings as part of performance tuning and capacity planning. Choosing the wrong level can waste money or cause application failures under load.

## Why it matters in exams

In the DP-900 Microsoft Azure Data Fundamentals exam, the concept of consistency levels appears under the objective "Describe core data concepts" and more specifically within the context of non-relational data offerings like Azure Cosmos DB. The exam expects you to recall the five consistency levels for Cosmos DB in order from strongest to weakest: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual. You should be able to identify which level provides the highest consistency and which provides the best performance. 

 The exam may present scenarios where you must recommend a consistency level based on application requirements. For instance, a question might describe an application that requires reads to always reflect the most recent writes, even if it increases latency. The correct answer would be Strong consistency. Another question might describe a global application where users only need to see their own updates immediately but can tolerate slight delays for other users' updates. The correct answer would be Session consistency. 

 The DP-900 exam also tests your understanding of the trade-offs involved. A common question type asks: "Which consistency level provides the highest availability and lowest latency?" The answer is Eventual consistency. You may also encounter questions about the default consistency level for Azure Cosmos DB accounts, which is Session consistency. Understanding that consistency levels are configurable per request as well as at the account level is important. The exam does not require deep implementation details like replica count or protocol specifics, but it does expect you to match consistency levels to common use cases such as IoT telemetry data (Eventual), real-time leaderboards (Strong), or user profiles (Session).

## How it appears in exam questions

Exam questions about consistency levels often fall into scenario-based, configuration, and comparison formats. A typical scenario question might read: "You are designing a global social media application that shows user posts. Users must see their own posts immediately after posting. Other users can see posts within a few seconds. Which consistency level should you choose?" The correct answer is Session consistency, because it guarantees read-your-writes within the same session while allowing eventual convergence for others. 

 Configuration questions might provide a screenshot of the Azure Cosmos DB configuration blade and ask: "Where do you change the default consistency level for your Cosmos DB account?" The answer is under the Default consistency setting, and you would select from the dropdown among the five levels. You might also be asked to identify which request-level override is possible using the x-ms-consistency-level header in the SDK. 

 Comparison questions often list two consistency levels and ask about their differences. For example: "What is the main difference between Strong and Eventual consistency?" The answer is that Strong guarantees that all reads return the most recent write, while Eventual makes no such guarantee and only ensures that replicas will converge over time. Troubleshooting-style questions might present a situation where an application experiences high latency or data conflicts, and you need to suggest changing the consistency level to a weaker or stronger one to resolve the issue. For instance, if a globally distributed app has slow writes, switching from Strong to Bounded Staleness can reduce latency while still maintaining a predictable staleness window.

## Example scenario

A company called ShopFast runs an online electronics store with customers all over the world. The store uses Azure Cosmos DB to manage its product catalog and user shopping carts. Product catalog data, such as descriptions and images, changes only once a month. For this data, the development team configures Eventual consistency because it keeps the database responsive and cost-effective. A customer in Australia sees the same product description as a customer in Brazil, though the Brazilian customer might see an update about ten seconds later. This delay is acceptable because the catalog updates are rare and not critical. 

 However, the shopping cart system requires high accuracy. When a customer adds an item, the inventory must be decremented exactly once. No two customers should be able to buy the same last item. For this data, the team uses Strong consistency. Every time a write happens, all replicas must acknowledge it before the system confirms the purchase. This ensures that inventory counts are always correct, preventing overselling. The trade-off is that checkout operations take slightly longer because the data must synchronize globally, but the guarantee of accuracy is worth it for the business. 

 During a Black Friday sale, the shopping cart system experiences heavy load. The team considers switching the cart database to Session consistency to improve performance, but they realize that Session consistency would allow a customer to see their own cart updates immediately but might let another customer see a stale inventory count. Since overselling would damage trust, they keep Strong consistency for cart operations even under load. Meanwhile, they optimize other parts of the application to reduce latency, such as caching product data with Eventual consistency. This scenario shows how different consistency levels serve different data requirements within the same application.

## Common mistakes

- **Mistake:** Thinking that Strong consistency always gives the best performance.
  - Why it is wrong: Strong consistency requires all replicas to synchronize before responding, which increases write latency and reduces write availability. It is actually the slowest consistency level in terms of write throughput.
  - Fix: Remember that Strong consistency prioritizes accuracy over speed. Use weaker levels when speed is more important than immediate accuracy.
- **Mistake:** Believing that Eventual consistency guarantees data will converge within a fixed time.
  - Why it is wrong: Eventual consistency does not guarantee any specific time bound. It only guarantees that if no new writes occur, replicas will eventually become consistent. Under heavy write load, convergence can be delayed.
  - Fix: If you need a predictable staleness bound, use Bounded Staleness instead of Eventual.
- **Mistake:** Confusing Session consistency with Strong consistency because of the word 'session'.
  - Why it is wrong: Session consistency provides per-session guarantees like read-your-writes, but it does not guarantee global linearizability like Strong consistency. Other clients outside the session may see stale data.
  - Fix: Know that Session consistency is weaker than Strong, and it only protects a single client session.
- **Mistake:** Assuming that all Azure data services support the same consistency levels as Cosmos DB.
  - Why it is wrong: Different Azure data services have different consistency models. For example, Azure SQL Database uses snapshot isolation and read committed, not the five levels of Cosmos DB.
  - Fix: Learn the specific consistency models for each service you study. Cosmos DB has five named levels; SQL databases use transaction isolation levels.

## Exam trap

{"trap":"Choosing Strong consistency for a globally distributed application that requires high write throughput and low latency because you think it is the safest option.","why_learners_choose_it":"Learners often default to Strong consistency because it feels like the most reliable choice. They underestimate the performance impact of global synchronization and overestimate how many applications actually need that level.","how_to_avoid_it":"Always read the scenario carefully. Look for keywords like 'low latency,' 'high throughput,' 'global users,' and 'tolerates slight delays.' If the scenario mentions acceptable inconsistency or eventual convergence, pick a weaker level like Eventual or Session. Only choose Strong when the description explicitly states that every read must return the most recent write at all costs."}

## Commonly confused with

- **Consistency level vs Transaction isolation level:** Transaction isolation levels (like read uncommitted, read committed, repeatable read, serializable) control how transactions interact with concurrent modifications within a single database. Consistency levels in distributed systems control how data is synchronized across multiple replicas. The focus of isolation levels is concurrency control, while consistency levels focus on replica synchronization. (Example: A bank transfer uses serializable isolation to prevent concurrency issues, but the account balance might be read from a replica using Session consistency to balance speed and accuracy.)
- **Consistency level vs CAP theorem:** The CAP theorem states that a distributed system can only guarantee two out of three properties: Consistency, Availability, and Partition Tolerance. Consistency levels are the practical implementation of the trade-offs described by CAP. But CAP is a theoretical model, while consistency levels are configurable settings in actual products like Cosmos DB. (Example: CAP explains why you cannot have perfect consistency and perfect availability during a network partition. Consistency levels let you choose which side of that trade-off to favor.)
- **Consistency level vs Staleness window:** A staleness window is a specific parameter used within Bounded Staleness consistency. It defines the maximum number of versions (K) or time (T) that reads can be behind writes. The term 'consistency level' is the broader category; the staleness window is a configuration detail inside one specific level. (Example: Setting Bounded Staleness with K=10 and T=5 seconds means reads will never be more than 10 versions or 5 seconds old, whichever comes first.)

## Step-by-step breakdown

1. **Write operation initiated** — An application sends a write request to the database, for example updating a user's profile name. The request goes to the nearest replica or the primary replica depending on the database architecture.
2. **Replica propagation** — The write is forwarded to all other replicas in the database cluster. The number of replicas and their geographic distribution affect how long this propagation takes. Consistency level controls how many replicas must acknowledge the write before it is considered committed.
3. **Acknowledgment collection** — Each replica sends back a success or failure message. Under Strong consistency, all replicas must acknowledge. Under Eventual, no acknowledgment is required before the write is considered complete. The database coordinator waits for the necessary acknowledgments based on the chosen level.
4. **Read operation requested** — A read request arrives, asking for the user's profile name. The database must decide which replica to read from. Consistency level determines whether it can read from any replica or must read from the replica that has the most recent write.
5. **Response delivered** — The database returns the data to the application. If Strong consistency was used, the data is guaranteed to be the latest across all replicas. If weaker consistency was used, the data might be from a replica that has not yet received the latest write. The application receives the response and continues its logic.

## Practical mini-lesson

In practice, consistency level is not a one-size-fits-all decision. As an IT professional, you need to map the consistency level to the specific data access patterns of your application. Start by listing all the read and write operations your application performs. For each operation, ask: What is the consequence if the user sees stale data? If the consequence is a financial error or a safety issue, you need Strong or Bounded Staleness. If the consequence is a slightly outdated recommendation or a minor delay, you can use Session, Consistent Prefix, or Eventual. 

 Once you have selected a level, test it under realistic load conditions. Azure Cosmos DB allows you to override the consistency level at the request level, so you can use a weaker default for most operations and override to Strong only for critical writes. This approach minimizes latency for the majority of traffic while protecting sensitive operations. 

 A common real-world configuration is to set the default consistency level to Session for user-facing applications. This provides a good balance: users see their own updates immediately, and the system still performs well globally. For internal analytics or batch processing, you can switch to Eventual consistency because the analytics can tolerate slight delays and benefit from low latency reads. 

 What can go wrong? If you use weak consistency and a network partition occurs, different clients might see different versions of the same data, leading to confusion. Also, if you use Strong consistency in a multi-region setup, writes might fail if a region is temporarily unreachable, reducing write availability. Monitoring the Request Unit (RU) consumption is also important; Strong consistency can consume more RUs per operation because of the additional coordination. 

 To configure consistency level in Azure Cosmos DB, you navigate to the account's default consistency blade in the Azure portal. You can also set it programmatically using the SDKs, such as setting the ConsistencyLevel property in the .NET SDK. For beginners, it is advised to start with the default Session consistency and only change to Strong or Eventual after thorough testing.

## Memory tip

Remember the order: Strong, Bounded, Session, Consistent, Eventual, think 'S-B-S-C-E' as 'Some Big Ships Carry Elephants'.

## FAQ

**Can I change the consistency level after creating my Azure Cosmos DB account?**

Yes, you can change the default consistency level for your Cosmos DB account at any time through the Azure portal, CLI, or SDK. However, changing it may affect ongoing requests and can cause temporary inconsistencies if you switch from Strong to a weaker level.

**Which consistency level is best for a real-time chat application?**

Session consistency is often best for chat applications because it ensures that a user sees their own messages immediately and sees messages in the correct order within their session. Other users might see slight delays, which is acceptable in many chat systems.

**Does Eventual consistency mean I might lose data?**

No, Eventual consistency does not cause data loss. All writes are persisted on some replica. It only means that reads may return stale data temporarily. Eventually, all replicas will have the same data.

**Can I use Strong consistency with multi-region writes in Azure Cosmos DB?**

No, Strong consistency is not supported when you enable multi-region writes. Strong consistency is only available with single-region writes and multiple read regions. For multi-region writes, the strongest available consistency level is Bounded Staleness.

**How does consistency level affect cost?**

Stronger consistency levels generally consume more Request Units (RU) per write operation because more replicas must be synchronized. This increases the cost of database operations. Weaker levels are more cost-efficient for high-throughput workloads.

**What is the difference between Consistent Prefix and Eventual consistency?**

Consistent Prefix guarantees that reads never see a version of data that is out of order. For example, if updates happen in order A then B, a read will always see A before B, never B without A. Eventual consistency does not provide any ordering guarantee; reads may see updates in any order.

## Summary

Consistency level is a fundamental concept in distributed databases like Azure Cosmos DB that controls how data is synchronized across replicas. It represents a deliberate trade-off between data accuracy and system performance. The five levels in Cosmos DB, from strongest to weakest, are Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual. Each level serves different application needs, from critical financial transactions to high-volume social media feeds. 

 For IT certification learners aiming for the DP-900 exam, understanding these levels and their appropriate use cases is essential. Exam questions test your ability to match consistency levels to real-world scenarios and explain the trade-offs involved. Memorizing the order and the primary guarantee of each level is a key step. 

 In practice, selecting the right consistency level requires analyzing the application's data sensitivity, latency requirements, and cost constraints. Using a weaker level by default and overriding to stronger consistency for critical operations is a common and effective strategy. As cloud computing continues to grow, mastering consistency levels will help you design resilient, cost-effective, and user-friendly distributed applications.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/consistency-level