Azure Cosmos DB is built with availability in mind. The underlying database of a Cosmos DB account is written to four replicas with any given region – this is the default and minimal configuration in regard to availability.

You can optionally create one or more replicas of your databases in any Azure region that supports Cosmos DB. Replicas in other regions are also replicated within that region to four other replicas. For example, suppose you set up your Cosmos DB account to be multi-region across two regions. In that case, you will have eight replicas of your data – four in the primary and four in the secondary regions.

Although data within a region is replicated four times, it is not stored across Availability Zones by default. This is an optional configuration applied to a Cosmos DB account in regions that support high-Availability Zones.

Another factor to consider when using Cosmos DB with global replication is whether to use single-region or multi-region writes. As the name would suggest, with single-region writes, data is written to the primary region only. This is, of course, useful for disaster recovery scenarios – in the event of a region outage, your secondary replica will become available for writing too.

Multi-region writes allow data to be written to multiple replicas at the same time. This is especially useful when you want to use your application’s global distribution options to achieve lower latency by enabling applications to write to their closest replica. For example, if your solution serves users in Europe and the USA, you could have replicas in both regions. Users in the USA would read and write from the USA replica, and users in Europe would read and write from the European replica. As writes are made to the closest replica, latency is considerably lower.

Replicas can be added and removed as needed. However, when enabling Availability Zone support, this has to be done when creating the replica. The following screenshot shows an example and the replica management page showing the options and a visual display of where replicas are placed:

Figure 14.7 – Azure Cosmos DB management

Having a globally distributed database can cause issues with consistency, however. Suppose you have data being replicated between regions. In that case, there will be a delay either in the time it takes to become consistent between replicas or to ensure all replicas are in sync before a write is acknowledged, which can decrease performance.

Whereas some technologies, such as Azure SQL, manage this as part of the service and do not provide any options, Azure Cosmos DB offers a range of consistency options and allows you to choose the best one according to your requirements.