Oskar Ekström
Oskar Ekström

Reputation: 3

Cosmos DB eventual consistency maximum upper bound

We're thinking about using Cosmos DB but can't find any information on what the maximum upper bound would be for eventual consistency, if any.

Can someone provide insight on this please?

Upvotes: 0

Views: 778

Answers (2)

Aravind Krishna R.
Aravind Krishna R.

Reputation: 8003

There's no upper bound. This is by design, to let you be highly available even in the event of a failure.

Let's say you have an account with West US as the primary, and East US were the secondary region. In normal operation, they will be up to date with each other (aside from ~60ms lag for replication/speed of light). In this scenario, there's no practical difference between Strong and Eventual consistency.

Let's look at a failure scenario. What if East US were to be down, say due to a natural disaster, or because the connectivity between West US and East US was severed. What would the Azure Cosmos DB database's behavior be?

  1. With Strong consistency, West US would stop taking writes to ensure that West US and East US don't drift apart.
  2. With Bound Staleness, you can configure a bounded staleness window, say 5 minutes. West US would continue to accept writes for 5 minutes, and East US may be stale by up to 5 minutes. Beyond 5 minutes, West US writes will be unavailable until connectivity to East US is restored. Then East US would catch up and writes can resume.
  3. With Eventual, West US would never stop taking writes. If East US was not down, but simply disconnected (network partition), it would serve stale reads. Again once the region is back up, East US would catch up and writes can resume.

Again, this is only in the event of failures, not for normal operation where regions are up to date with each other, save for the replication/speed of light latency.

For further discussion, please email the team at [email protected]

Upvotes: 2

Jesse Carter
Jesse Carter

Reputation: 21147

There are no SLAs around maximum time to expect eventual consistency. The key here in the documentation is this point: Eventual consistency guarantees that in absence of any further writes, the replicas within the group *eventually* converge.

Basically what this boils down to is if you pick this level of consistency it will entirely depend on different factors such as your provisioned throughput (how much is available in order to keep the replicas in sync), the frequency with which documents are being updated and queried, etc. You're opting into the behavior that the timeframe for consistency is not important to your application.

I'd be curious to know more about your potential workload (specifically why you think eventual consistency may be a good fit) as the vast majority of customers favour either Session or Bounded Staleness.

Upvotes: 0

Related Questions