Consistency

Cosmos DB scales out in order to follow through on its latency, throughput and availability promises. This creates a potential consistency problem if different replicas disagree on the states of persisted items.

To address this, Cosmos offers a spectrum of consistency levels ranging from strong consistency with lower availability, throughput and higher latency to weak consistency with the opposite.

• Strong: strongest consistency
• Bounded staleness
• Session
• Consistent prefix
• Eventual: weakest consistency

Your choice of consistency level is guaranteed to be respective regardless of:

• The region that performed the read/write
• The number of regions you specify as available
• Whether writes are enabled in one or more regions

Choosing a consistency level

You can change your default consistency level at the Cosmos DB account level at any time. The consistency level you choose applies to all databases and containers under that account. All reads against a container use this level by default.

The consistency level you choose has precise availability and performance tradeoffs that need to be considered.

Strong

Reads are guaranteed to return the most recent committed version of an item. A client never sees an uncommitted or partial write.

Bounded staleness

In bounded staleness, you choose a level of staleness that you are comfortable accepting when reading data. Acceptable staleness can be configured in two ways:

• number of versions (K)
• time interval (T)

If the data lag in a region exceeds the configured staleness value, writes for that partition are throttled until staleness is back within the configured upper bound.

Writes are replicated to a local majority (three replicas in a four replica set).

Session

Within a single client session, reads are guaranteed to honour the read-your-writes and write-follows-reads guarantees. This consistency level assumes a single writer or multiple writers sharing a single session token.

Writes are replicated to a local majority (three replicas in a four replica set).

Consistent prefix

Updates made as single document writes see eventual consistency. Updates made as a batch within a transaction are guaranteed to be consistent with each other.

If two documents are updated in a transaction (A, B), reads following this update will either see (A1, B1) or (A2, B2) - never (A1, B2).

Writes are replicated to a local majority (three replicas in a four replica set).

Eventual

No ordering guarantee for reads. Replicas eventually converge assuming that writes stop occurring for enough time. The client may read an item which is older than one it read previously.

Writes are replicated to a local majority (three replicas in a four replica set).