Cosmos DB Consistency

Introduction

Cosmos DB maintains two extra replicas of a database apart from the primary database.
All reads are distributed across three copies.
All writes to the primary are replicated across two secondary replicas.
The process of updating replicas takes time.
If read request goes to replica yet to update, the client may get an older data or inconsistent data.

Consistency Models

Cosmos DB allows developers to choose between five well-defined consistency models along the consistency spectrum.

Strong Consistency

This is the strongest form of the consistency.
It ensures that the requested data is most recent.
Read requests are guaranteed to return the latest version of an item.
The cost of the read operation is higher in terms of RUs (Request Units).
Performance is lowest in comparison to other consistency policies as read needs to wait until all writes are committed.
It is useful in critical applications, like Stock Market, Banking, Airline Reservation.

Bounded staleness

A client might see old data but one can specify a limit for how old that data can be (e.g. 2 sec).
It ensures all the updates on replicas happen in the order they are received.
The "staleness window" can be configured in two ways: Maximum Number of Operations, Maximum duration.
The cost of a read operation is lower than that in Strong Consistency if the request is within "staleness window".
Performance is better than Strong Consistency when a request is within "staleness window".

Session

Session consistency is scoped to client session.
It is default consistency provided by Cosmos DB.
It provided Read Your Own (RYW) guarantee.
The client reads its own writes, but other clients reading this same might see older values.
The cost of a read operation is lower than both the previous Consistency policies.
Performance is much better than other two policies mentioned above.

Consistent Prefix

This can not guarantee the freshness of data but makes sure that reads never see out of order writes.
If the write is happening in order of A, B, C, then a client may read either A or AB or ABC and not the out of order.
The cost of the read operation is lower than all three policies mentioned above.
Performance is also better than other three policies.

Eventual

Eventual consistency is the weakest form of consistency where a client may get the values that are older than the ones it had seen before.
The client might see old data for as long as it takes a write to propagate to all replicas.
Highest performance and availability is ensured but a client might sometimes read out-of-date information or see updates out of order.

How to set Consistency?