How do distributed databases provide geo-replication?

Distributed databases achieve geo-replication by automatically copying and synchronizing data across multiple geographically dispersed servers. This is done to improve availability, reduce latency for users in different regions, and protect against data loss during outages. The process typically involves configuring the database to replicate writes (e.g., inserts, updates) from one region to others, often using built-in protocols to handle network delays, conflicts, and consistency guarantees. For example, a database cluster in North America might replicate its data to nodes in Europe and Asia, allowing applications to read or write locally while the system handles cross-region synchronization in the background.

The specifics depend on the database’s replication model. Some systems use asynchronous replication, where data is copied to other regions after a write is confirmed locally. This minimizes latency for the user but risks temporary inconsistencies if a failure occurs before replication completes. Others use synchronous replication, requiring all regions to acknowledge a write before it’s considered successful, which ensures strong consistency at the cost of higher latency. Many databases also support hybrid approaches, like allowing per-operation consistency levels or quorum-based writes. For instance, Amazon DynamoDB Global Tables uses asynchronous replication with eventual consistency, while Google Spanner combines synchronous replication with atomic clocks to enforce strong consistency across regions.

Conflict resolution is critical in geo-replicated systems. When the same data is modified in two regions simultaneously, databases use strategies like “last write wins” (based on timestamps), application-defined merge functions, or consensus algorithms like Raft. For example, Apache Cassandra allows developers to configure conflict resolution rules at the schema level, such as prioritizing the latest timestamp. Modern systems like Azure Cosmos DB let users choose between five consistency levels (e.g., strong, bounded staleness) to balance performance and correctness. Under the hood, these systems rely on distributed logs, vector clocks, or specialized protocols like CRDTs (Conflict-Free Replicated Data Types) to track and reconcile changes across regions efficiently.