In an Active-Passive setup, if US-East goes down, you manually fail over to US-West. This causes downtime. In an Active-Active setup, both US-East and US-West serve live traffic simultaneously. If one dies, global load balancers simply reroute traffic transparently.

Module 1: The Database Replication Problem

Stateless app servers are easy to run Active-Active. Databases are incredibly hard. If a user in Europe and a user in the US update the same record at the exact same millisecond, which write wins?

Conflict Resolution Strategies

  • Last Writer Wins (LWW): Relies on synchronized clocks (like Google Spanner's TrueTime) to pick the latest timestamp.
  • Application Logic: The database keeps both conflicting writes as 'siblings', and the application code must merge them on read.
  • CRDTs (Conflict-Free Replicated Data Types): Mathematical data structures that automatically merge concurrent modifications safely.

Module 2: Global Load Balancing

You use Anycast IP or Geo-DNS to route the user to their nearest data center. A globally distributed router (like AWS Route53 or Cloudflare) constantly monitors the health of all regions and adjusts routing in real-time.

dns_routing.yamlyaml
Type: Latency-Based Routing
Records:
  - Region: us-east-1
    Endpoint: east.api.company.com
  - Region: eu-central-1
    Endpoint: eu.api.company.com
  - Region: ap-southeast-1
    Endpoint: ap.api.company.com

Module 3: True Global Databases

To avoid writing custom replication logic, enterprises use natively distributed databases like CockroachDB, YugabyteDB, or DynamoDB Global Tables, which handle cross-region consensus and replication transparently.