Multi-Region Database — Database Scaling

Multi-Region Database means maintaining database infrastructure across multiple geographic regions so the system can continue operating even if an entire region becomes unavailable.

Why Do We Need Multi-Region?

Multi-AZ protects against an Availability Zone failure. But what happens if an entire cloud region becomes unavailable?

flowchart LR
    A[Users] --> B[Region 1]

    B --> C[Database]

    B --> D[Region Failure]

With Multi-Region:

flowchart LR
    A[Users] --> B[Global Routing]

    B --> C[Region 1]
    B --> D[Region 2]

    C -. Database Replication .-> D

If Region 1 becomes unavailable, traffic can be directed to Region 2 according to the application's disaster-recovery strategy.

Typical Multi-Region Architecture

flowchart TD
    A[Global Users] --> B[Global DNS / Traffic Manager]

    B --> C[Region 1]
    B --> D[Region 2]

    C --> E[ASP.NET Core API]
    D --> F[ASP.NET Core API]

    E --> G[Primary Database]
    F --> H[Secondary Database]

    G -. Cross Region Replication .-> H

Multi-AZ vs Multi-Region

SQL Server Multi-Region Example

For SQL Server, one approach is to have a primary database in Region 1 and a replicated secondary in Region 2 using an appropriate SQL Server high-availability or disaster-recovery configuration.

flowchart LR
    A[Region 1
Primary]

    A -. Replication .-> B[Region 2
Secondary]

    B --> C[DR / Failover Target]

1. Create the Database

CREATE DATABASE OrdersDb;
GO

USE OrdersDb;
GO

CREATE TABLE Orders
(
    OrderId BIGINT PRIMARY KEY,
    CustomerId BIGINT NOT NULL,
    Amount DECIMAL(18,2) NOT NULL,
    Status VARCHAR(30) NOT NULL,
    CreatedAt DATETIME2 NOT NULL
);
GO

2. Insert Data

INSERT INTO Orders
    (OrderId, CustomerId, Amount, Status, CreatedAt)
VALUES
    (1, 101, 1000.00, 'Completed', '2026-09-25'),
    (2, 102, 2500.00, 'Pending', '2026-09-26'),
    (3, 103, 4500.00, 'Completed', '2026-09-27');
GO

3. Verify Data

SELECT
    OrderId,
    CustomerId,
    Amount,
    Status,
    CreatedAt
FROM Orders
ORDER BY OrderId;
GO

Expected output:

OrderId  CustomerId  Amount   Status      CreatedAt
-------  ----------  -------  ----------  -------------------
1        101         1000.00  Completed   2026-09-25
2        102         2500.00  Pending     2026-09-26
3        103         4500.00  Completed   2026-09-27

The schema and data would be replicated to the secondary region using the chosen SQL Server replication/HA mechanism. The exact setup depends on the deployment environment and SQL Server architecture.

ASP.NET Core Web API — Region Routing

The application should not simply hardcode Region 1.

A global routing layer can direct users to a healthy region.

sequenceDiagram
    participant User
    participant DNS as Global DNS
    participant API1 as Region 1 API
    participant API2 as Region 2 API
    participant DB1 as Region 1 DB
    participant DB2 as Region 2 DB

    User->>DNS: api.example.com
    DNS->>API1: Route to Region 1
    API1->>DB1: Query
    DB1-->>API1: Result
    API1-->>User: Response

    Note over API1,DB1: Region 1 failure

    User->>DNS: api.example.com
    DNS->>API2: Route to Region 2
    API2->>DB2: Query
    DB2-->>API2: Result
    API2-->>User: Response

ASP.NET Core Controller

[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly OrdersDbContext _db;

    public OrdersController(OrdersDbContext db)
    {
        _db = db;
    }

    [HttpGet("{id:long}")]
    public async Task<IActionResult> GetOrder(long id)
    {
        var order = await _db.Orders
            .AsNoTracking()
            .FirstOrDefaultAsync(x => x.OrderId == id);

        if (order == null)
            return NotFound();

        return Ok(order);
    }
}

The controller does not need to know whether it is running in Region 1 or Region 2. The regional deployment provides the appropriate database connection.

Connection Configuration

Region 1:

{
  "ConnectionStrings": {
    "OrdersDb":
      "Server=region1-sql;Database=OrdersDb;..."
  }
}

Region 2:

{
  "ConnectionStrings": {
    "OrdersDb":
      "Server=region2-sql;Database=OrdersDb;..."
  }
}

The same ASP.NET Core application can be deployed to both regions with environment-specific configuration.

Program.cs

builder.Services.AddDbContext<OrdersDbContext>(options =>
{
    options.UseSqlServer(
        builder.Configuration
            .GetConnectionString("OrdersDb"),
        sqlOptions =>
        {
            sqlOptions.EnableRetryOnFailure(
                maxRetryCount: 5,
                maxRetryDelay: TimeSpan.FromSeconds(10),
                errorNumbersToAdd: null);
        });
});

builder.Services.AddControllers();

var app = builder.Build();

app.MapControllers();

app.Run();

Normal Operation

flowchart LR
    A[User] --> B[Global DNS]

    B --> C[Region 1 API]
    C --> D[Region 1 Database]

    D -. Replication .-> E[Region 2 Database]

Region Failure

flowchart LR
    A[User] --> B[Global DNS]

    B -. Region 1 Unavailable .-> C[Region 2 API]
    C --> D[Region 2 Database]

    E[Region 1 API] --> F[X Unavailable]
    G[Region 1 Database] --> H[X Unavailable]

The global routing layer detects the unhealthy region according to its configured health-check and routing strategy and directs traffic to the available region.

What About Writes?

This is one of the most important Multi-Region design questions.

There are several possible models:

Single-Writer Model

flowchart LR
    A[Region 1 API] --> B[Primary Database]

    C[Region 2 API] --> B

    B -. Replication .-> D[Region 2 Secondary]

This simplifies write consistency because there is one primary writer.

Active-Active Model

flowchart LR
    A[Region 1 API] --> B[Region 1 Database]

    C[Region 2 API] --> D[Region 2 Database]

    B -. Replication .-> D
    D -. Replication .-> B

Active-active can provide better regional availability and local write performance, but conflict resolution and consistency become significantly more complex.

Replication Lag

Cross-region replication may not be instantaneous.

sequenceDiagram
    participant API as Region 1 API
    participant DB1 as Region 1 DB
    participant DB2 as Region 2 DB

    API->>DB1: Write Order
    DB1-->>API: Success

    DB1-->>DB2: Replicate Order
    Note over DB1,DB2: Replication delay

If Region 1 fails immediately after acknowledging a write, Region 2 may not contain the latest transaction depending on the replication design.

This is directly related to RPO.

Read Routing

For globally distributed users, reads can be routed to a nearby healthy region.

flowchart TD
    A[Global Users] --> B[Global Traffic Manager]

    B --> C[India Users]
    B --> D[US Users]

    C --> E[India Region API]
    D --> F[US Region API]

    E --> G[India Database]
    F --> H[US Database]

This can reduce network latency, but the design must account for replication lag and consistency requirements.

Multi-Region vs Read Replica

Important Interview Point

Multi-Region does not automatically mean zero data loss.

The amount of data potentially lost during a regional failure depends on the replication model and replication lag.

Therefore, when designing Multi-Region systems, always discuss:

• RPO
• RTO
• Replication mode
• Consistency requirements
• Failover strategy
• Data conflict handling

Interview Scenario

Interviewer: Your application is running in Bangalore and Mumbai regions. Bangalore suddenly goes down. How does the system continue?

Answer: I would deploy the application and database infrastructure in both regions. A global DNS or traffic-management layer would detect the unhealthy region and route users to Mumbai. The Mumbai database would contain replicated data according to the chosen replication strategy. The application would use the local region's database connection through environment-specific configuration. I would also define RPO and RTO because cross-region replication may introduce replication lag.

Common Interview Questions

• Why do we need Multi-Region databases?
• Multi-AZ vs Multi-Region?
• How does database replication work across regions?
• Active-active vs active-passive?
• How do you handle writes in multiple regions?
• What happens if replication is delayed?
• How does ASP.NET Core connect to the regional database?
• How does global traffic routing work?
• What happens during a complete region failure?
• How are RPO and RTO related to Multi-Region architecture?

Key Takeaways

• Multi-Region protects against regional failures.
• Application infrastructure and database replicas can exist in multiple geographic regions.
• Global DNS or traffic management can route users to a healthy region.
• Single-writer architectures simplify consistency.
• Active-active architectures provide more flexibility but introduce conflict and consistency challenges.
• Cross-region replication can have latency.
• Always define RPO and RTO.
• Multi-Region does not replace backups.

Conclusion

Global Users
      ↓
Global Traffic Manager
      ↓
Healthy Region
      ↓
ASP.NET Core Web API
      ↓
Regional Database
      ↓
Cross-Region Replication
      ↓
Disaster Recovery

For interviews, remember: Multi-AZ protects against infrastructure-zone failures; Multi-Region extends the design to survive a complete regional failure.