A SaaS company serves customers in Europe, North America and Asia from one database region. Distant users report slow page loads caused by read queries, and the business also wants the data to survive the loss of the entire hosting region. Which approach addresses both needs?
Select an answer to reveal the explanation.
Short Explanation
Here's the trick: you've got two problems, distance and a single region, and only one answer fixes both. Geo-replication puts readable copies close to each crowd of users and, as a bonus, outside your home region. Read replicas in the same region help load, sure, but if that region goes dark they go dark with it.
Full Explanation
Geo-replication maintains copies of the database in different geographic regions, typically asynchronously because of the distance. Readable secondaries placed near each user population let read queries be served locally, cutting the network round trip that causes slow page loads. Because the secondaries live outside the primary region, one of them can be promoted if the whole hosting region is lost, which satisfies the disaster recovery requirement. Mirroring to a standby in another availability zone of the same region protects against a single facility failure, but the copy is still in the same region and usually not readable, so it neither speeds up distant users nor survives a regional outage. Read replicas inside the current region spread read load across more servers, but distant users still cross continents to reach them, and the replicas share the region's fate. Partitioning tables across disks on the primary server can improve local I/O and maintenance, yet it adds no copy of the data and does nothing about geographic latency. Exam caveat: asynchronous geo-replicas can return slightly stale reads and may lose recent commits on failover, so writes and read-your-own-write paths need care. Operational check: measure read latency from each user region before and after, and track replication lag on each secondary against the RPO.