Azure Cosmos DB and High Availability
5 November 2019
I went to Microsoft Cosmos DB hands-on workshop a few weeks ago and came back with renewed enthusiasm about NoSQL database. After working with relational database for many years I had inadvertently formed a bias opinion against non-relational database. I must admit I’m pleasantly surprised to learn that Cosmos DB is backed by performance SLA (i.e. read/write request latency < 10ms) and not the stock standard four 9s or five 9s availability offered by most cloud vendors. Network latency is a critical design element for high-volume and latency sensitive application. It is also a major impediment for engineering Active-Active distributed application. For example, a sluggish online shopping website will undoubtedly impact general user experience and thus deter potential customer and sales. As a matter of fact most cloud applications are subject to latency constraints. E.g. the latency between your on-premises data centre, the user geographic distribution and the cloud provider. Apart from the Cosmos DB latency SLA, multi-master replication across different regions is another standout feature. Image you have configured Cosmos DB running in 2 regions and lets pick Australia East (Sydney) and Australia Southeast (Melbourne). Armed with multi-master replication between Sydney and Melbourne (i.e. write request can be processed by both regions simultaneously) you can deploy the application in the same 2 regions operated in truly Active-Active always-on architecture. It is the epitome of a highly available, scalable and performing distributed cloud application.
Sourced from Azure Cosmos DB Documentation
Assuming at this point you are sufficiently impressed by Cosmos DB and can’t wait to find out how to convert the tiring old relational database to Cosmos DB. Surely your manager will be impressed too, right? Prior to taking further action I think it is prudent to step back and consider the very first architecture principle: is it fit for purpose? Cosmos DB is a non-relational database and it is not designed for maintaining data integrity and complex relationship. Typically Cosmos DB data model is fully or partially denormalised for maximum performance. So, if you are working with an online shopping application which requires global presence, highly available and low latency read (i.e. SELECT) and write (i.e. INSERT) operation then Cosmos DB is the godsend without doubt. On the other hand if you are working with expansive complex data model and convoluted data transformation warehouse application then Cosmos DB is probably not the best candidate.
Check out the following Azure Cosmos DB high availability documentation for more details and start leveraging some of the most advanced cloud features on offer.
https://docs.microsoft.com/en-us/azure/cosmos-db/high-availability