Consistency Levels in CosmosDB

This blog will allow us in understanding Consistency Levels in CosmosDB. These levels are the settings that controls the trade-off between data availability and its consistency within a distributed database system. Cosmos DB is a globally distributed, multi-model database service offered by Microsoft Azure. The consistency level is one of the critical parameters that you need to configure to match the specific targeted requirements of your application.

Following is the basic figure which allows you to understand about all the consistency level with bird view.

Consistency Levels in CosmosDB (5 Levels)

Lets deep dive into the 5 consistency levels in CosmosDB:

Strong Consistency 

High level of consistency in Azure Cosmos DB ensures always bringing the most recent version of data for reading purposes. This type of consistency style guarantees all replicas across distributed nodes are updated before a write operation is confirmed, therefore giving the system a view that is both up-to-date and synchronized. For example, in this case, after writing a new document to the database, the user immediately reads it, with an assurance to see the latest version of that document.

A banking application is implemented where a user initiates a fund transfer. With a high consistency, the account balance queries will always be correctly replicated to all replicas thereafter, hence delivering a strong and recent snapshot. Additionally, with a high guarantee of providing the correct response, high consistency would lead to higher latency or lower availability as it needs to wait for synchronization across its distributed nodes.

Bounded Staleness Consistency 

Bounded staleness is yet another compromise – between strong consistency, on the one hand, and eventual consistency, on the other – which enables you to define the window under which read operations are bound to return results that will be guaranteed to have some lag from the last write. Either time or the number of writes can define the window in question.

For instance, a bounded staleness banking application. Assume that a user credits his account and then checks his balance. It guarantees that the effect of the credit will be visible in the read operation for some time bound or count of write operations but does not carry the same constraints or requirements as does strong consistency.

The maximum lag configuration balances the trade-off between consistency and performance based on the needs of the application. Bounded staleness is appropriate when applications require near-real-time consistency but where absolute latest state is not strictly required on every read operation for flexible and customizable consistency management.

Session Consistency 

There is session consistency level in Azure Cosmos DB, intended to ensure a high consistency within a session or client context. Under this model, all the read as well as write operations are guaranteed to reflect the most recent write within the same session. Normally, a session is defined by a user or an application client and identified by a session token.

Suppose you had a multi-user document editing application where lots of people are working on the same document. If User A makes some edits to the document and saves it, then every subsequent read that user makes in the same session will always reflect those edits. Now, if User B, operating in a different session, queries the document concurrently, he is not going to necessarily immediately see the edits made by User A, at least until the modification are committed and replicated through the database.

A consistency level that is useful for an application where a user or client keeps up a persistent connection or state with the database, such that all interactions would reflect the most recent writes. It strikes a balance between the effectiveness of strong consistency and the performance and availability requirements of distributed systems, offering a tailored solution for applications whose session-specific consistency needs are bespoke.

Consistency Prefix Consistency 

The guarantee for prefix consistency in Azure Cosmos DB is that the reads never observe stale writes, meaning that the order of the writes is preserved. It doesn’t necessarily mean that the latest write is always visible; it guarantees that the system maintains the order of operations across all the replicas while performing a write.

Consider a messaging app, where messages are written to a store and then read back from the store. With consistency model Consistent Prefix, that gives the guarantee that if User A has written two messages consecutively, then any later read operation would see the messages in the order they were actually sent, but there’s no such guarantee that a read operation would instantly reflect the most recently sent message if another write operation was also in progress simultaneously.

This consistency level is used when the chronological order of events has to be maintained, such as event sourcing or auditing systems. It offers a compromise between the strong consistency model and eventual consistency, balancing the system’s need to preserve the sequence of operations against some level of latency to reflect the latest updates.

Eventual Consistency 

Eventual consistency is a degree of consistency in Azure Cosmos DB that allows eventually all changes in replicas to be reconciled. In this system, it does not guarantee that the read operation will represent the most recent write immediately but that over time all replicas should eventually reach the same value. This approach prefers availability and low latency over strict consistency.

Consider an update posting social network site. When user A posts a new post, differing replicas may not show it immediately to all users, with eventual consistency. However, once enough time is taken for replication to take place, eventually each replica will hold the same set of posts. This consistency level is suitable for scenarios where true consistency in real-time is not mandatory but there may be minor lags in propagating updates.

Eventual consistency offers high availability and fault tolerance while being quite well matched for the nature of a distribution database globally. Temporary consistency is tolerated when traded in with the promise that eventually the system will reach a consistent state across all replicas without compromising system responsiveness. Applications that can tolerate eventual convergence, such as content distribution systems, will come to appreciate the basic scalability and responsiveness in this consistency model.

Conclusion on Consistency Levels in CosmosDB

The appropriate level of consistency for your application would depend on the respective demands for availability versus performance. The most extreme level of consistency would be achieved at a cost in terms of high latency & low availability with strong consistency. Eventual consistency provides better availability and lower latency but comes at a cost of a lower level of consistency. It really becomes more the specific needs of an application and the kinds of trade-offs an application is willing to make.

Do feel free to Contact Us or Schedule a Call to discuss any of your projects

Author : Naishadh R. Patel