Users run application instances that sit between their end users (clients) and the database itself. These application instances are what a client’s browser (or

Users run application instances that sit between their end users (clients) and the database itself. These application instances are what a client’s browser (or mobile app, IoT device, etc) interact with. The application in turn connects to the database. Many users start simple, and run their application instances in only one region, with the database in that region as well. However, by spreading the database across three regions, the database itself can actually maintain availability (reads and writes continue) even if there is a region-wide outage due to MongoDB’s built in replication and auto-failover. Developers can run their application instances in multiple regions and serve nearby clients from them, and achieve low-latency in-region reads to MongoDB cluster replicas in those regions. In this model, writes would go to the region with the MongoDB database primary, however, meaning users in some regions would have a cross-region network hop in order to perform writes. MongoDB does have a concept called geo-zoned sharding, however, which makes it possible to have different write regions for different shards, which makes it possible to have users in different parts of the world actually achieve low latency reads and writes.