Cosmos DB: Consistency Levels

To continue with my topic of Cosmos DB this week, today I’ll discuss the data consistency models that are supported within the context of Cosmos DB. If you don’t already know, data consistency is the ability of the data to be read once it has been written. When choosing a consistency model, you want to take into consideration consistency, availability and latency.

As you begin to understand what’s going on with Cosmos DB, you’ll realize that we need to have a variety of models. In most scenarios, we have 2 models.

• A strong model, which says you can’t read anything until it’s all the way committed to every node that’s readable. Typically, we see this in database structures and SQL Server. What we really want is a transactional model that can mix everything, so we have the advantage of consistent reads. The trade off is that it takes a long time, thus we have a lot of latency while waiting for things to commit and to make sure everything is happening the way we expect it to in the database.
• Cosmos can do strong, so the reads are guaranteed to the most recent version of the item and there’s no inconsistency with the data. However, it’s very limiting in its approach in how you can leverage the power of Cosmos within the environment.

• The extreme opposite side is eventual. Basically, this means eventually we’re going to get our data consistent; the changes are going to show up eventually and they may not show up in order. Rarely an acceptable scenario, the exception being log files since we want to look at log files after the fact, not when they’re being written. Consistency will eventually straighten itself out.

But that’s not a good solution either. What Cosmos DB brings to the table is 3 options with consistency:

1. Session – The most common use case, with over 50% of customers using Session in the platform. Session guarantees that you’re able to see what you wrote. So, if I’m working in the application, I’m going to have a consistent read and write experience.

I get a good user experience, while also not having to wait for everything to fully commit around the globe or for the other pieces to happen to make sure it will eventually catch up. You’ll be able to read your writes, it’s going to come in the right order and all the data will be there.

2. Consistent Prefix – With this you’ll get some of the stuff updated as it starts to go, and the data will come in the right order, but there’s no guarantee that you’re going to get all the pieces you’re expecting. It gives you the opportunity to see less latency in your operation but get more read possibilities.

3. Bounded Staleness – This is where you’ll draw a boundary around what you want to be strong and what you don’t. This is a level deeper towards the strong side from Session. In this case, the reads will lie behind the writes, but you know the interval that you’re lagging. Also, that there’s going to be some inconsistencies over a smaller period of time, but you don’t need to wait for everything to commit. It goes beyond the scope of Session.

We have all these consistency levels available inside Cosmos DB to meet the needs of our various applications. All of these are guaranteed on SLAs. Microsoft guarantees your consistency model will work within the confines that you’ve given the application to work in.

Keep in mind, you need to weigh out things like lower latency with better read scalability and higher availability. If you can live with the latency and it’s more important that you get consistent reads, then you’ll want to lean towards strong. Point being, you have options.

If you’d like to learn more about consistency models in Cosmos DB or any other Azure related topic or product, we are your best resource. Click the link below or contact us—we’re here to help.