{"id":669,"date":"2020-05-06T00:00:00","date_gmt":"2020-05-06T00:00:00","guid":{"rendered":""},"modified":"2023-05-11T15:26:34","modified_gmt":"2023-05-11T22:26:34","slug":"minecraft-earth-and-azure-cosmos-db-part-1-extending-minecraft-into-our-real-world","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/minecraft-earth-and-azure-cosmos-db-part-1-extending-minecraft-into-our-real-world\/","title":{"rendered":"Minecraft Earth and Azure Cosmos DB part 1: Extending Minecraft into our real world"},"content":{"rendered":"

This post is part 1 of a two-part series about how organizations use Azure Cosmos DB to meet real world needs and the difference it\u2019s making to them. In part 1, we explore the challenges that led service developers for Minecraft Earth to choose Azure Cosmos DB and how they\u2019re using it to capture almost every action taken by every player around the globe\u2014with ultra-low latency. In part 2<\/a>, we examine the solution\u2019s workload and how Minecraft Earth service developers have benefited from building it on Azure Cosmos DB.<\/i><\/p>\n

Extending the world of Minecraft into our real world<\/h2>\n

You\u2019ve probably heard of the game Minecraft, even if you haven\u2019t played it yourself. It\u2019s the best-selling video game of all time, having sold more than 176 million copies since 2011. Today, Minecraft has more than 112 million monthly players, who can discover and collect raw materials, craft tools, and build structures or earthworks in the game\u2019s immersive, procedurally generated 3D world.<\/a> Depending on game mode, players can also fight computer-controlled foes and cooperate with\u2014or compete against\u2014other players.<\/p>\n

In May 2019, Microsoft announced the upcoming release of Minecraft Earth, which began its worldwide rollout in December 2019. Unlike preceding games in the Minecraft franchise, Minecraft Earth takes things to an entirely new level by enabling players to experience the world of Minecraft within our real world through the power of augmented reality (AR).<\/p>\n

For Minecraft Earth players, the experience is immediately familiar\u2014albeit deeply integrated with the world around them. For developers on the Minecraft team at Microsoft, however, the delivery of Minecraft Earth\u2014especially the authoritative backend services required to support the game\u2014would require building something entirely new.<\/p>\n

Nathan Sosnovske, a Senior Software Engineer on the Minecraft Earth services development team explains:<\/p>\n

\u201cWith vanilla Minecraft, while you could host your own server, there was no centralized service authority. Minecraft Earth is based on a centralized, authoritative service\u2014the first \u2018heavy\u2019 service we\u2019ve ever had to build for the Minecraft franchise.\u201d<\/em><\/p>\n

In this case study, we\u2019ll look at some of the challenges that Minecraft Earth service developers faced in delivering what was required of them\u2014and how they used Azure Cosmos DB to meet those needs.<\/p>\n

The technical challenge: Avoiding in-game lag<\/h2>\n

Within the Minecraft Earth client, which runs on iOS-based and Android-based AR-capable devices, almost every action a player takes results in a write to the core Minecraft Earth service. Each write is a REST POST that must be immediately accepted and acknowledged to avoid any noticeable in-game lag.<\/p>\n

\u201cFrom a services perspective, Minecraft Earth requires low-latency writes and medium-latency reads,\u201d explains Sosnovske. \u201cWrites need to be fast because the client requires confirmation on each one, such as might be needed for the client to render\u2014for example, when a player taps on a resource to see what\u2019s in it, we don\u2019t want the visuals to hang while the corresponding REST request is processed. Medium-latency reads are acceptable because we can use client-side simulation until the backing model behind the service can be updated for reading.\u201d<\/em><\/p>\n

To complicate the challenge, Minecraft Earth service developers needed to ensure low-latency writes regardless of a player\u2019s location. This required running copies of the service in multiple locations within each geography where Minecraft Earth would be offered, along with built-in intelligence to route the Minecraft Earth client to the nearest location where the service is deployed.<\/p>\n

\u201cTypical network latency between the east and west coasts of the US is 70 to 80 milliseconds,\u201d says Sosnovske. \u201cIf a player in New York had to rely on a service running in San Francisco, or vice versa, the in-game lag would be unacceptable. At the same time, the game is called Minecraft Earth\u2014meaning we need to enable players in San Francisco and New York to share the same in-game experience. To deliver all this, we need to replicate the service\u2014and its data\u2014in multiple, geographically distributed datacenters within each geography.\u201d<\/em><\/p>\n

The solution: An event sourcing pattern based on Azure Cosmos DB<\/h2>\n

To satisfy their technical requirements, Minecraft Earth service developers implemented an event sourcing pattern<\/a> based on Azure Cosmos DB<\/a>.<\/p>\n

\u201cWe originally considered using Azure Table storage to store our append-only event log, but its lack of any SLAs for read and write latencies made that unfeasible,\u201d says Sosnovske. \u201cUltimately, we chose Azure Cosmos DB because it provides 10 millisecond SLAs for both reads and writes, along with the global distribution and multi-master capabilities needed to replicate the service in multiple locations within each geography.\u201d <\/em><\/p>\n

With an event sourcing pattern, instead of just storing the current state of the data, the Minecraft Earth service uses an append-only data store that\u2019s based on Azure Cosmos DB to record the full series of actions taken on the data\u2014in this case, mapping to each in-game action taken by the player. After immediate acknowledgement of a successful write is returned to the client, queues that subscribe to the append-only event store handle postprocessing and asynchronously apply the collected events to a domain state maintained in Azure Blob storage<\/a>. To optimize things further, Minecraft Earth developers combined the event sourcing pattern with domain-driven design, in which each app domain\u2014such as inventory items, character profiles, or achievements\u2014has its own event stream.<\/p>\n

\u201cWe modeled our data as streams of events that are stored in an append-only log and mutate an in-memory model state, which is used to drive various client views,\u201d says Sosnovske. \u201cThat cached state is maintained in Azure Blob storage, which is fast enough for reads and helps to keep our request unit costs for Azure Cosmos DB to a minimum. In many ways, what we\u2019ve done with Azure Cosmos DB is like building a write cache that\u2019s really, really resilient.\u201d<\/em><\/p>\n

The following diagram shows how the event sourcing pattern based on Azure Cosmos DB works:<\/p>\n

\"Event<\/p>\n

Putting Azure Cosmos DB in place<\/h2>\n

In putting Azure Cosmos DB to use, developers had to make a few design decisions:<\/p>\n

Azure Cosmos DB API.<\/b> Developers chose to use the Azure Cosmos DB Core (SQL) API because it offered the best performance and the greatest ease of use, along with other needed capabilities.<\/p>\n

\u201cWe were building a system from scratch, so there was no need for a compatibility layer to help us migrate existing code,\u201d Sosnovske explains. \u201cIn addition, some Azure Cosmos DB features that we depend on\u2014such as TransactionalBatch<\/a>\u2014are only supported with the Core (SQL) API. As an added advantage, the Core (SQL) API was really intuitive, as our team was already familiar with SQL in general.\u201d<\/em><\/p>\n

Read Introducing TransactionalBatch in the .NET SDK<\/a> to learn more.<\/p>\n

Partition key.<\/b> Developers ultimately decided to logically partition the data within Azure Cosmos DB based on users.<\/p>\n

\u201cWe originally partitioned data on users and domains\u2014again, examples being inventory items or achievements\u2014but found that this breakdown was too granular and prevented us from using database transactions within Azure Cosmos DB to their full potential,\u201d says Sosnovske.\u201d<\/em><\/p>\n

Consistency level.<\/b> Of the five consistency levels supported by Azure Cosmos DB<\/a>, developers chose session consistency, which they combined with heavy etag checking<\/a> to ensure that data is properly written.<\/p>\n

\u201cThis works for us because of how we store data, which is modeled as an append-only log with a head document that serves as a pointer to the tail of the log,\u201d explains Sosnovske. \u201cWriting to the database involves reading the head document and its etag, deriving the N+1 log ID, and then constructing a transactional batch operation that overwrites the head pointer using the previously read etag and creates a new document for the log entry. In the unlikely case that the log has already been written, the etag check and the attempt to create a document that already existed will result in a failed transaction. This happened regardless of whether another request \u2018beats\u2019 us to writing or if our request reads slightly out-of-date data.\u201d<\/em><\/p>\n

In part 2<\/a> <\/strong>of this series, we examine the solution\u2019s current workload and how Minecraft Earth service developers have benefited from building it on Azure Cosmos DB.<\/p>\n

Get started with Azure Cosmos DB<\/h2>\n