Global Database: One Logical DB, Multiple Regions
A global database is a single logical database that spans multiple geographic regions, providing fast local reads and disaster recovery. It's used for apps with a worldwide user base that must survive regional outages.
Why it exists
Traditional single-region databases create two problems for global applications: high latency for users far from the data center, and the risk of a complete outage if that single region fails. A global database solves both by distributing data closer to users while maintaining a coherent disaster recovery strategy.
The mental model
A global database is like having a master blueprint in one city and highly accurate, automatically updated copies in offices worldwide. Local teams can consult their copy instantly for information (fast local reads). If the main office is hit by a meteor (a regional outage), one of the other offices can be designated as the new master in minutes, ready to approve new changes (promote to write).
How it works
A global database consists of a primary cluster in one geographic region and one or more secondary, read-only clusters in other regions. The primary cluster handles all write operations. These changes are then replicated to all secondary regions, typically at the storage layer using dedicated infrastructure. This replication is asynchronous but very fast, with latencies often under one second. Applications in a secondary region can read from their local cluster for low-latency data access. If the primary region fails, a secondary cluster can be promoted to become the new primary, taking over write responsibilities. This failover process is designed to be very fast, often under a minute.
When to use it
Use a global database for applications with a worldwide user base that require fast read performance everywhere, such as gaming, financial services, or travel booking sites. It is critical for applications with stringent business continuity requirements that must survive a complete regional outage with minimal data loss (low Recovery Point Objective, or RPO) and minimal downtime (low Recovery Time Objective, or RTO).
When not to use it
This architecture is overkill for applications serving a geographically concentrated user base. It is also not the right fit if your application requires multi-region, simultaneous writes (a multi-master or multi-active setup). A global database has a single write primary; all other regions are read-only replicas, which introduces replication lag (even if small) and a single point for write bottlenecks.
One canonical example
A financial trading application has users in New York, London, and Tokyo. The primary database is in a US region. It replicates data to secondary regions in Europe and Asia with sub-second latency. Traders in London and Tokyo experience fast local reads for market data. If the entire US region experiences an outage, the London region can be promoted to primary in under a minute, allowing trading to continue with a potential data loss of at most one second (RPO=1s, RTO<1min).
Interview question
Which statement accurately describes a fundamental architectural characteristic of a global database?
- a.It ensures immediate data consistency across all regions for every write operation.
- b.It designates a single primary region to handle all write operations, with others serving as read-only replicas.Correct
- c.It is primarily optimized for applications serving a geographically concentrated user base.
- d.It allows any regional cluster to accept and process write operations simultaneously.
Why? this is the answer
The card explicitly states that "A global database has a single write primary; all other regions are read-only replicas," meaning only one region handles all write operations. Option A is incorrect because replication is asynchronous, not immediate, introducing a small lag before consistency across all regions.
Just read this? Test yourself on what you have been reading.
Read the original → aws.amazon.com
- #database
- #cloud
- #distributed systems
- #disaster recovery
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on database — each one lists the topics its interview covers.
See open roles