In this article, we will dive into different consistency levels provided by Azure Cosmos DB. There are five types of consistency levels provided by Azure.
- Eventual
- Consistent Prefix
- Session
- Bounded Staleness
- Strong
In each consistency level, we measure the consistency and availability supported by it. Here, consistency means that every read operation should be current with the latest writes and availability means that every request should get a response.
Consider a scenario where our read/write DB is created in the USA region and two users are trying to fetch the records from two different regions, one is from Spain and another one is from India. Now, based on their geographical distance to our read/write database, the read time may vary.
So, in order to overcome such kind of situation, Azure Cosmos DB provides the facility of replication and options to select the consistency level based on your requirement.
Eventual
Eventual consistency is the weakest form of consistency wherein a client may get the values which are older than the ones seen before, over time. In the absence of any further writes, the replicas within the group will eventually converge.
The eventual consistency is ideal where the application does not require any ordering guarantees. For example - the count of retweets, likes, or non-threaded comments.
In our scenario, there might be a possibility that two different users get two different values while accessing the same database as replication is done eventually. So, you can't be sure if you will have the latest reads always.
Session
Session consistency is most widely used consistency level both for a single region as well as globally distributed applications. It provides write latencies, availability, and read throughput comparable to that of eventual consistency but also provides the consistency guarantees that suit the needs of the application written to operate in the context of the user.
In our scenario,
Represents read write database
Represents replication database
User reads from the database
At 12.00 PM, the value in the read/write database and replication DBs is the same; i.e., A. When any user tries to read the data, he will get 'A' only. Now, one user (user1) changes the data in the read/write DB from 'A' to 'B' and then tries to read. Well, he will get the updated value 'B' whereas the other users will get 'A' only because the session consistency reads the latest for that session only. Once the sync happens successfully, all the users can get the updated value i.e. 'B'.
Strong
Strong consistency provides the most predictable and intuitive programming model. When you configure your account with strong consistency level, Azure Cosmos DB provides linearizability guarantee. This means that reads are guaranteed to see the most recent writes.
Even though User1 has changed the value from 'A' To 'B' at 12.05 pm, all the users are getting 'A' only until complete sync has not happened. So, in this way, the strong consistency level is highly consistent.
Bounded Staleness
The Bounded Staleness consistency is most frequently chosen by globally distributed applications expecting low write latencies but total global order guarantees. Unlike strong consistency which is scoped to a single region, you can choose bounded staleness consistency with any number of read regions (along with write region). Bounded staleness is great for applications featuring group collaboration and sharing, stock ticker, publish-subscribe/queueing etc.
Sync will be done at a preconfigured time. In our scenario, we set it every three hours. So, at 3.00 pm, the sync happens and users get the updated value, i.e., 'B'.
Consistent Prefix
The Consistent Prefix level guarantees that reads see out of order writes. If writes were performed in the order 'A, B, C', then a client sees either 'A', 'A,B' or 'A,B,C', but never out of order like 'A,C' or 'B,A,C'. Consistent prefix provides write latencies, availability, and read throughput is comparable to that of eventual consistency, but also provides the order guarantees that suit the needs of scenarios where the order is important.
Availability is low to high while the consistency is high to low from Strong to Eventual. So, if you are looking for high consistency and low availability, then go for Strong and for vice versa, go for Eventual. By default, the Session consistency level is set for Cosmos DB.
In the next article, we will discuss about partitioning in Cosmos DB.