Building distributed systems is hard. When you’re working with applications that span a planet, the speed of light is a brake on what you want to do, complicating data replication among servers and services. Someone buys a widget in Hong Kong at almost the same time as someone in Paris, but there’s only one in stock. How do you know who to bill, and who to tell the purchase failed? Whose purchase ends up being the one recorded in your line-of-business tools?
Azure as a distributed systems platform
Microsoft’s Azure drives work in distributed system design, powering services built around stateless microservices. Managing applications that work across this fabric requires two things: an effective way of handling messaging traffic and a way of handling distributed data at scale.
Microsoft Research’s work on its Orleans virtual actor framework handles the messaging side of the equation, both on its own in services like Xbox and as the basis for the actor/message patterns used in Azure Service Fabric. Meanwhile the data side is handled by Cosmos DB, Microsoft’s global-scale distributed database.
Cosmos DB is a fascinating piece of work, especially when you look at it as a practical implementation of some very complex computer science concepts. Instead of only offering either eventual or strong consistency models, like other cloud-scale systems, it offers a balance between accuracy and latency with three other models that map more closely to application design patterns and intentions. All five consistency models have high service levels, quickly replicating data among different instances and reducing the risk of conflicts. It’s these conflicts that cause issues like multiple purchases of the same item—issues that can’t be allowed to affect your business.
