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,
  • Bounded staleness
  • Session (Default Consistency)
  • Consistent prefix
  • Eventual
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?

  • Log in to Azure Portal.
  • Go to Cosmos DB account.
  • Click on "Default Consistency" option.
  • Set "Consistency" as per requirement.
  • Click on "Save".