openskills.info
Course catalog
Course Preview

Multi-Region Database Architecture

Multi-region database architecture places related database replicas in separate geographic regions. It keeps data near distant users or preserves service through a regional outage, while making latency, consistency, failover, and data-location tradeoffs explicit.

itDatabases and data storage

Multi-region database architecture runs one logical data service across two or more geographic regions. Each region contains a database replica, shard, or cluster that participates in reading, writing, replication, or recovery. The architecture reduces distance between users and data and gives an application another location when a region fails. It also turns network delay and partition behavior into database design constraints.

A region is a provider-defined geographic area. Availability zones inside one region protect against local infrastructure failures, but they do not create regional isolation. A multi-region design crosses the region boundary. That distinction matters because replication traffic now traverses a wide-area network with higher and more variable latency.

The data path

A request first reaches an application instance through global traffic routing. The application chooses a database endpoint based on the workload's write authority, read consistency, and data-location rules. A local replica can answer some reads without a cross-region round trip. A write may need to reach one primary region, a partition's home region, or a quorum of voting replicas.

The database records the write locally and propagates it according to its replication model. Synchronous replication waits for enough voting replicas to acknowledge before commit. This can preserve strong consistency across regions, but the commit path includes wide-area latency. Asynchronous replication acknowledges earlier and sends the update later. It lowers foreground write latency, but creates replication lag and a possible recovery point gap.

Replicas are not automatically interchangeable. A read-only replica can serve local reads but cannot accept writes. A voting replica participates in commit decisions. A witness can vote without storing a complete copy. A multi-active replica accepts writes in more than one region and therefore needs either coordination before commit or a deterministic way to reconcile concurrent updates.

Continue the course

This section is part of the paid course.

See pricing to subscribe, or log in if you already have access.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources