Geo‑Distribution
& Multi‑Region
Architecture

// Raft cluster: US-East (leader), EU-West, AP-Southeast
// Quorum = 2 of 3. Client writes from US-East.

Write latency = time until quorum ACK
  US-East → EU-West round trip:  ~85ms
  US-East → AP-Southeast RT:     ~140ms

Quorum write latency = min(EU-West RTT, AP-Southeast RTT) = ~85ms
// must wait for 1 of 2 remote nodes to ACK

// This means every write to your database takes 85ms minimum.
// A 10ms SLA is IMPOSSIBLE with synchronous global Raft.

// Solution: non-voting replicas (CockroachDB style)
// US-East: 2 voting replicas (quorum = 2, all local → ~1ms write latency)
// EU-West: 1 non-voting replica (async replication, ~1s lag)
// AP-Southeast: 1 non-voting replica (async replication, ~1s lag)
// Write latency: ~1ms (local quorum) ✓
// EU/APAC reads: served locally (slightly stale) ✓

class GCounter:
    def __init__(self, node_id, num_nodes):
        self.node_id = node_id
        self.counts = [0] * num_nodes   # slot per node

    def increment(self):
        self.counts[self.node_id] += 1  # only increment OWN slot

    def value(self):
        return sum(self.counts)

    def merge(self, other):             # merge another replica
        self.counts = [max(a, b)
            for a, b in zip(self.counts, other.counts)]

# Simulation: 3 nodes
A = GCounter(0, 3); A.increment(); A.increment(); A.increment()  # [3,0,0]
B = GCounter(1, 3); B.increment(); B.increment()                 # [0,2,0]
C = GCounter(2, 3); C.increment()                                # [0,0,1]

A.merge(B); A.merge(C)  # [3,2,1] → value = 6
B.merge(A); B.merge(C)  # [3,2,1] → value = 6
# All replicas converge to 6 regardless of merge order ✓

// Architecture: table replicated across N AWS regions
// Each region: accepts reads AND writes independently
// Replication: asynchronous, bidirectional, ~1s lag
// Conflict resolution: LAST-WRITE-WINS (timestamp-based)

// GOOD USES (LWW acceptable):
✓ User sessions: {user_id → session_token, last_seen}
✓ User preferences: {user_id → theme, language, notifications}
✓ Shopping cart: {user_id → cart_items} (last write wins per user)
✓ Configuration flags: {feature_flag → enabled/disabled}

// BAD USES (LWW causes data loss):
✗ Financial balances: concurrent increments → one lost
  User in US adds $100, user in EU adds $50 simultaneously
  One write wins → balance shows +$100 OR +$50, not +$150
✗ Inventory: concurrent decrements → overselling
✗ Leaderboard rankings: concurrent score updates

// For counters: use DynamoDB Streams + Lambda to consolidate
// Or: use a CRDT service (PN-Counter semantics)
// Or: route all writes for a given key to its "home" region

// Cost: each additional replica region ≈ 2× storage + throughput costs
// Replication lag: typically ~1s, can spike to ~5s under high load

-- Set survival goal: lose an entire region without data loss
ALTER DATABASE mydb SURVIVE REGION FAILURE;

-- REGIONAL BY ROW: each row pinned to its home region
-- EU user's rows stored in EU region → EU reads/writes at 5ms latency
ALTER TABLE users SET LOCALITY REGIONAL BY ROW AS region;

-- User in EU: crdb_region='eu-west-1' → row stored in EU → fast local access
INSERT INTO users (id, name, crdb_region) VALUES (1, 'Alice', 'eu-west-1');

-- REGIONAL TABLE: entire table anchored to one region
-- Good for: tables only accessed from one region
ALTER TABLE eu_compliance_log SET LOCALITY REGIONAL IN 'eu-west-1';

-- GLOBAL: replicated everywhere, optimized for reads everywhere
-- Writes need global consensus (slower), reads are local (fast)
-- Good for: product catalog, reference data, configuration
ALTER TABLE product_catalog SET LOCALITY GLOBAL;

-- Follower reads: slightly stale (~4.8s) but instant from any region
-- Good for: analytics, dashboards, non-critical reads
SELECT * FROM orders AS OF SYSTEM TIME follower_read_timestamp()
WHERE user_id = 123;

// Given: 99.99% availability SLA (52 min/year downtime budget)
// Incident: detect=15min, page team=5min, fix=30min → 50 min per incident
// → Budget allows ZERO incidents that go over 52 min/year
// → Need automatic failover with RTO < 30s

// Payment service (financial data):
RPO = 0      → synchronous replication  (zero data loss)
RTO = 30s    → hot standby, auto-promote (no manual steps)
Cost:         higher write latency, expensive hot standby

// Analytics service (aggregate counts):
RPO = minutes → periodic snapshots         (some loss OK)
RTO = hours   → restore from snapshot      (downtime OK)
Cost:         cheap backup storage, no standby infra

// Product catalog (semi-static data):
RPO = seconds → async replication           (small loss OK)
RTO = minutes → warm standby, semi-auto    (brief outage OK)
Cost:         moderate — warm standby only