Course contentsShow
← Databases & SQL
Lesson 485 of 1,9535. Relational Schema ArchitectureFree lesson

Multi-Region Schema Synchronization

Architect databases that handle conflicting writes and replication delays across geographically distant sites.

In this lesson, you will learn how to architect your database schema to remain consistent and functional when your application spans multiple geographic regions.

When you deploy a database across the globe—say, one instance in New York and another in Tokyo—you face the "speed of light" problem: data cannot replicate instantly. If a user in New York updates a row at the same millisecond a user in Tokyo updates the same row, your schema needs a strategy to handle the conflict without corrupting the data.

1. Conflict Resolution at the Schema Level

To manage conflicting writes, you should avoid relying on database-generated auto-incrementing integers, as these create collisions between regions. Instead, use UUIDs (as discussed in Lesson 3) to ensure every record has a globally unique identifier.

To handle the actual conflict, add a version column to your tables. When a record is updated, the database checks the version number. If the version in the database is higher than the version being submitted, the update is rejected, forcing the application to resolve the drift.

CREATE TABLE user_profiles (
    user_id UUID PRIMARY KEY,
    username TEXT,
    bio TEXT,
    version INT DEFAULT 1, -- Tracks record state
    last_modified_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

2. Handling Replication Delay

Replication delay means a read performed immediately after a write in a different region might return stale data. Your schema architecture should embrace Eventual Consistency (Lesson 1). By designing your application to be "version-aware," you can ensure that the system only processes changes that are newer than the current local state.

When performing migrations across regions, you must apply them in an additive, non-breaking fashion. Use your Schema Versioning Patterns (Lesson 9) to ensure that the Tokyo region doesn't attempt to write to a column that the New York region hasn't finished creating yet. By treating the schema as a distributed object that evolves slowly, you avoid downtime during the synchronization window.

Key Takeaway: Use global identifiers like UUIDs and version columns to detect and resolve write conflicts across distant regions while respecting the natural latency of replication.