Azure Cosmos DB offers a range of choices for defining consistency between replicas, known as consistency models. Strong consistency and eventual consistency are at two different ends of the spectrum, and this can help developers make a clear choice concerning high availability and performance.

The five consistency models are as follows:

• Strong: Strong consistency is the easiest model to understand. The most recent committed version of an item is returned when the data is read. A partial or uncommitted write is never returned to the client. This will give a lot of overhead because every instance needs to be updated with the latest version of the data, which has a huge price in terms of the data’s latency and throughput.
• Bounded staleness: This is a compromise that trades delays for strong consistency. This model doesn’t guarantee that all the observers have the same data at the same time. Instead, it allows a lag of 5 seconds (100 operations).
• Session: This is the default level for newly created databases and collections. It is half as expensive as strong consistency, and it offers good performance and availability. It ensures that everything that is written in the current session is also available for reading. Anything else will be accurate but delayed.
• Consistent prefix: With this level, updates that are returned contain accurate data for a specific point in time but won’t necessarily be current.
• Eventual: There’s no ordering guarantee for how long it will take to synchronize (like the consistent prefix), and updates aren’t guaranteed to come in order. However, this is the most performant model for response times. When there are no further writes, the replicas will eventually be updated.

You can configure a change of the desired consistency model at any time, either through the portal or programmatically through PowerShell, the CLI, or REST APIs. The portal shows a graphical example of how the consistency models work in practice, as shown in the following screenshot:

Figure 14.8 – Setting the Cosmos DB consistency model

Such fine-grained controls over consistency, the placement of replicas, and the ability to have read/write replicas anywhere in the world make Azure Cosmos DB the ideal solution for globally spanning applications as it enables you to have your data close to your customer while still ensuring uniformity.

Summary

In this chapter, we concluded Part 4, Applications and Databases by looking at the options for introducing high availability into our solutions.

Although many Azure components provide a redundancy level by default, some services require availability to be designed in, and others offer different levels of resilience depending on your needs.

We also looked at how we can apply these concepts to Azure VMs using scale sets, which enable us to automate the scaling of VMs based on demand and thresholds we can set.

We also looked at the different Azure storage accounts and databases, namely Azure SQL and Azure Cosmos DB. These services provide a default level of local redundancy, meaning you are protected against hardware failure. However, we examined how this can be extended across regions should it be required.

In the next chapter, we begin Part 5, Operations and Monitoring, starting with the different ways to set up logging and monitoring components.

Exam scenario

MegaCorp Inc. has an e-commerce application that they wish to expand to serve global customers, but they are concerned about performance. Local distribution centers in each region (the Americas, Europe, and Asia) perform their order shipping and management. The performance and a local view of stock levels within each region are important. However, a consolidated global view is still required for reporting purposes, but as reports are run in the evening, an up-to-date view of levels across regions is not required.

Currently, the application is built using traditional VMs because it requires specific OS components and custom modules to be installed. The backend database has been built with NoSQL in mind, currently being used on a Mongo DB. The application team has tested and confirmed the solution can be migrated to Cosmos DB using the MongoDB APIs with little effort.

Currently, there are only 2 VMs and a load balancer running the application. Although these VMs are at maximum capacity during busy periods, there are also occasions when they experience very low usage.

All components currently run in Azure but only in the East US region. Tests with customers outside the US have confirmed low response times.

Suggest a potential strategy to the management team that could help improve the application’s efficiency and performance.