Consistency Levels in Azure Cosmos DB with an Example

Introduction

In my articles, we have covered the basics of Azure Cosmos DB as well as the implementation in the real-time application with the create, read, update, and delete operations. If you want to learn more about the previous article, then use the following link.

Azure Cosmos DB is a globally distributed database with the capability to facilitate rapid reading and writing of data, contingent on the chosen consistency levels. In simpler terms, Azure Cosmos DB is a robust, globally distributed database engineered for exceptional speed in both data retrieval and storage. The consistency levels represent distinct operational modes that ensure the fulfillment of its speed-related commitments. In this article, we will learn about a more detailed exploration of these consistency levels.

What are Consistency Levels in Azure Cosmos DB?

The consistency level in Azure Cosmos DB determines how quickly you can read data that has been written or inserted into the database. In other words, when you write data to Cosmos DB, the consistency level determines how long it will take for that data to be readable by other operations.

Azure

The Azure Cosmos DB has five different consistency levels, as follows.

Strong
Bounded staleness
Session
Consistent prefix
Eventual

Strong Consistency Level

This level provides the highest level of consistency, meaning that all read and write operations are guaranteed to be consistent. When you write data to Cosmos DB and then immediately read that data, you are guaranteed to get the same data back. This means that if you store information in Cosmos DB (a type of database), and right away you try to retrieve or read that information, you'll get exactly what you just stored. There's a guarantee that the data you put in is the same data you'll get out.

However, this level may result in slower performance compared to the other levels. But there's a trade-off. This process might take a bit longer compared to some other ways of using Cosmos DB. The system ensures data consistency (getting back what you just put in), and sometimes this comes at the cost of speed. So, even though you're sure to get the correct data, it might take a bit more time than some other methods.

Scenario to use Strong Consistency Level

Consider the GoPure App, an online sweets ordering application that caters to customers' cravings for delectable treats. In this scenario, the use of Azure Cosmos DB with a Strong Consistency Level becomes crucial in specific situations where absolute data accuracy is paramount.

For instance, consider the scenario where a customer places an order for a unique and limited-edition sweet. The availability of this sweet is highly dynamic and can change rapidly based on real-time updates. With a strong consistency level in Azure Cosmos DB, you ensure that every user interacting with the GoPure App receives the most up-to-date information regarding the availability of this exclusive sweet.
In this context, Strong Consistency guarantees that when a customer places an order, and the app confirms the availability of the sweet, that information remains consistent and accurate throughout the entire ordering process. Whether it's checking out the item, confirming the order, or updating inventory, every operation reflects the latest state of the data.
This level of consistency is crucial to preventing scenarios where multiple users might attempt to order the last piece of the limited edition sweet simultaneously. Strong consistency ensures that the order confirmation and inventory update occur in a way that avoids conflicts, maintaining a reliable and accurate representation of the available stock.

In summary, for critical scenarios in the GoPure App, such as limited edition sweets with dynamic availability, the Strong Consistency Level in Azure Cosmos DB ensures that users receive precise and consistent information, offering a seamless and reliable experience in the online sweets ordering process.

Bounded Staleness Consistency Level

This level allows some degree of inconsistency in the data but guarantees that any read operation will not return data that is more than a certain number of versions or time intervals behind the latest write.

If you set the staleness to 5 minutes, any read operation will return data that is at most 5 minutes old. It means "staleness" refers to how much time can pass before the data you read is considered out-of-date. If you set it to 5 minutes, it means that when you perform a read operation (retrieve information from the database), the data you get will be, at most, 5 minutes old. In other words, you're accepting that the information you read might be as recent as 5 minutes ago but not more recent than that. This allows a balance between having somewhat recent data and not putting too much load on the system by constantly requiring the absolute latest information.

Scenario to use Bounded Staleness Consistency Level

In the scenario of GoPure App order tracking, customers can place orders for various sweets and track the status of their orders in real time. The application relies on a distributed database like Azure Cosmos DB to store and manage order data. To ensure a consistent and reliable order tracking experience, the Bounded Staleness Consistency Level can be applied.

Customers want to see the latest status of their orders as quickly as possible.
With bounded staleness, you can configure an acceptable lag (staleness) period, allowing the application to read data that is a few seconds behind the writes. This ensures near-real-time visibility into the order status.
Since bounded staleness allows for a certain level of staleness, read operations can be optimized for lower latency.
This is crucial for displaying the order status quickly to customers without waiting for full consistency, making the tracking experience smoother.
Bounded staleness can help in scenarios where occasional delays in consistency are acceptable, but high availability is crucial.
In cases of temporary network partitions or node failures, the application can continue to serve read requests with an acceptable level of staleness, ensuring continuous operation.

Bounded Staleness Configuration

Configure bounded staleness with parameters such as maximum staleness duration or maximum lag in versions. For example, you might allow data to be read with a staleness of up to 5 seconds.

"consistencyPolicy": {
  "defaultConsistencyLevel": "BoundedStaleness",
  "maxStalenessPrefix": 5,
  "maxStalenessIntervalInSeconds": 5
}

Bounded Staleness Limitations

While Bounded Staleness provides low-latency reads, it's essential to communicate this to users, making them aware that they might see the order status with a slight delay.
Critical updates, such as order cancellations or inventory adjustments, might require stronger consistency levels. Evaluate the impact of staleness on such scenarios.
Regularly monitor the system to ensure that the staleness configured is acceptable and aligns with the user experience expectations.

By leveraging the Bounded Staleness Consistency Level in Azure Cosmos DB, the GoPure App can balance the need for near-real-time order tracking with the benefits of reduced latency and improved availability.

Session Consistency Level

This level provides a consistent view of the data within a single session. If a client establishes a session with Cosmos DB, all read and write operations within that session will be consistent. When you write data to Cosmos DB and then immediately read that data within the same session, you are guaranteed to get the same data back. This means that if you put information into Cosmos DB (a type of database) and then quickly try to retrieve or read that information without closing your current session (a connected period of activity), you're sure to get exactly the same data you just stored. The guarantee is that, as long as you're in the same session, the data you read will be the data you wrote.

Scenario to use Session Consistency Level

It's crucial that within a user session, the user sees the latest updates to the shopping cart and order details without any inconsistency. While strong consistency is essential within a user session, the application can tolerate eventual consistency across different user sessions to improve overall system availability and performance.

User Session Handling: When a user logs in or starts a session, the application connects to Azure Cosmos DB using the Session Consistency Level. This ensures that all read and write operations within the user session are strongly consistent. Any updates made to the shopping cart or order details are immediately visible to the user.
Order Placement: When a user decides to place an order, the application performs a series of updates to the Cosmos DB. This includes updating the order status, deducting items from inventory, and recording the transaction details. The use of session consistency guarantees that all these updates are reflected consistently within the user's session.
Read Operations Across Sessions: For scenarios where the application displays general product information or lists of available sweets (read-heavy operations that don't depend on the specific user session), the application can use a lower consistency level, such as "Eventual Consistency." This provides flexibility across different user sessions and helps improve overall system performance.
Strong Consistency Within Sessions: Users experience strong consistency within their sessions, ensuring they always see the latest updates to their shopping cart and order details.
Improved Performance Across Sessions: By allowing eventual consistency for read operations across different sessions, the application can benefit from lower latency and improved overall performance.
Balanced Trade-off: The use of session consistency allows the application to strike a balance between strong consistency where needed and flexibility in consistency for other scenarios.

Consistent Prefix Consistency Level

This level guarantees that read operations will always return the most recent write operation, but it does not guarantee that all previous write operations will be reflected in the read. When you write data A, B, and C to Cosmos DB in that order, a read operation may return either A and B or B and C, but not A and C. This means that if you store information in Cosmos DB in the sequence A, B, and C, when you later try to read that data, you might get either A and B or B and C as a pair, but you won't get both A and C together. The order in which you wrote the data is preserved, but the database might not give you a guarantee that you'll always see all consecutive pairs in the same read operation.

Scenario to use Consistent prefix Consistency Level

GoPure relies heavily on real-time inventory management and order processing to ensure a seamless experience for customers. The inventory needs to be updated in real-time as customers place orders, and customers expect accurate and up-to-date information about product availability.

Consider Challenges in the GoPure App

Multiple users are accessing and updating the inventory simultaneously.
Orders are placed frequently, leading to a high volume of read-and-write operations on the database.
Consistency in inventory levels is crucial to preventing overselling or underselling of products.

Solution using Azure Cosmos DB with Consistent Prefix

The Consistent Prefix Level in Azure Cosmos DB ensures that reads are guaranteed to reflect a prefix of the writes. In this scenario, it means that customers will see a consistent order of updates to the inventory.
When a customer places an order, the application updates the inventory in the Cosmos DB in real-time.
The Consistent Prefix Consistency Level ensures that subsequent read operations, such as checking product availability, will always reflect the latest updates in the order they were committed. This prevents customers from seeing inconsistent or outdated inventory information.
Customers get real-time and accurate information about product availability.
With Consistent Prefix, the application ensures that the inventory is never in an inconsistent state, reducing the risk of overselling or underselling products.
Users experience a seamless and reliable ordering process with up-to-date inventory information.

Limitation

While Consistent Prefix provides strong consistency guarantees, it may introduce slightly higher latency compared to eventual consistency. However, for scenarios where real-time and accurate data are critical, the trade-off in latency is often justified.

By leveraging the Consistent Prefix level in Azure Cosmos DB, the GoPure app can maintain a reliable and real-time inventory system, ensuring a smooth experience for customers and preventing any issues related to inconsistent or outdated product information.

Eventual Consistency Level

This level provides the lowest level of consistency, meaning that it may take some time for write operations to be reflected in read operations. This level is useful for scenarios where high availability is more important than consistency. When you write data to Cosmos DB and then immediately read that data, you may not necessarily get the same data back, but the data you do get will eventually reflect all of the write operations.

This means that if you store information in Cosmos DB (a type of database) and quickly try to read that information, you might not immediately see the exact same data you just stored. However, over time, the data you read will eventually include all the information from the write operations you performed. In short, there might be a delay, but the database will catch up and show all the changes you made.

Scenario to use Eventual Consistency Level

In the context of the GoPure app, an online sweets ordering app, let's explore a scenario where Azure Cosmos DB's Eventual Consistency level would be appropriate. In GoPure, the app aims to provide personalized recommendations to users based on their preferences. User preferences are stored in a distributed manner across multiple regions to ensure low-latency access. The eventual consistency model is suitable for this scenario, where real-time consistency is not critical, and the system can tolerate temporary inconsistencies.

Challenges

Users access the GoPure app from different regions, and their preferences need to be stored and retrieved quickly.
Multiple instances of the app may update user preferences simultaneously.
Achieving low-latency access to user preferences is crucial for providing a responsive and personalized user experience.

Solution using Azure Cosmos DB with Eventual Consistency:

Eventual consistency allows the system to achieve a balance between availability and consistency. It ensures that, over time, all replicas of the data will converge to the same state. However, there is no guarantee of immediate consistency.
When a user updates their preferences (e.g., liking or disliking certain sweets), the application writes these changes to the distributed Cosmos DB database.
The eventual consistency model allows for asynchronous replication of data across multiple regions, enabling low-latency access to user preferences.
Users experience low-latency access to their preferences as the system prioritizes availability and responsiveness.
The eventual consistency model supports the distribution of data across multiple regions, allowing the system to scale horizontally to handle an increased load and user base.

Limitations

Temporary Inconsistencies Due to the eventual consistency model, there may be temporary inconsistencies between replicas. However, these inconsistencies are resolved over time as the system converges to a consistent state.

By utilizing the Eventual Consistency level in Azure Cosmos DB, the GoPure app can provide users with low-latency access to their personalized recommendations while accommodating the distributed nature of user preferences across multiple regions. This approach is suitable for scenarios where immediate consistency is not a strict requirement, and the focus is on responsiveness and scalability.

Summary

I hope, from all the examples above, you have learned that the Azure Cosmos DB offers multiple consistency levels, including Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual. Each level provides a tailored trade-off between consistency and performance, allowing developers to choose the most suitable model for their specific application requirements. If you like it, share it with your friends and follow me on Csharpcorner for more such types of articles.

Related articles