multi-region-deployment

What this skill does

# Multi-Region Deployment

Comprehensive guide to deploying applications across multiple geographic regions for availability, performance, and disaster recovery.

## When to Use This Skill

- Designing globally distributed applications
- Implementing disaster recovery (DR)
- Reducing latency for global users
- Meeting data residency requirements
- Achieving high availability (99.99%+)
- Planning failover strategies

## Multi-Region Fundamentals

### Why Multi-Region?

```text
Reasons for Multi-Region:

1. High Availability
   └── Survive region-wide failures
   └── Natural disasters, power outages
   └── Target: 99.99%+ uptime

2. Low Latency
   └── Serve users from nearest region
   └── Reduce round-trip time
   └── Better user experience

3. Data Residency
   └── GDPR, data sovereignty laws
   └── Keep data in specific countries
   └── Compliance requirements

4. Disaster Recovery
   └── Business continuity
   └── RTO/RPO requirements
   └── Regulatory requirements

Trade-offs:
+ Higher availability
+ Lower latency globally
+ Compliance capability
- Higher cost (2x-3x or more)
- Increased complexity
- Data consistency challenges
```

### Deployment Models

```text
Model 1: Active-Passive (DR)
┌─────────────────┐         ┌─────────────────┐
│  PRIMARY (Active)│         │ SECONDARY (Passive)│
│  ┌─────────────┐│         │  ┌─────────────┐│
│  │     App     ││   ──►   │  │    App      ││
│  │    (Live)   ││  Sync   │  │  (Standby)  ││
│  └─────────────┘│         │  └─────────────┘│
│  ┌─────────────┐│         │  ┌─────────────┐│
│  │     DB      ││   ──►   │  │    DB       ││
│  │  (Primary)  ││  Replic │  │  (Replica)  ││
│  └─────────────┘│         │  └─────────────┘│
└─────────────────┘         └─────────────────┘
    All traffic              Failover only

Model 2: Active-Active (Load Distributed)
┌─────────────────┐         ┌─────────────────┐
│   REGION A       │         │   REGION B       │
│  ┌─────────────┐│    ◄──► │  ┌─────────────┐│
│  │     App     ││  Users  │  │     App     ││
│  │   (Active)  ││  routed │  │   (Active)  ││
│  └─────────────┘│   by    │  └─────────────┘│
│  ┌─────────────┐│ location│  ┌─────────────┐│
│  │     DB      ││    ◄──► │  │     DB      ││
│  │  (Primary)  ││  Replic │  │  (Primary)  ││
│  └─────────────┘│   Both  │  └─────────────┘│
└─────────────────┘  ways   └─────────────────┘
  Serves Region A           Serves Region B

Model 3: Active-Active-Active (Global)
┌──────┐    ┌──────┐    ┌──────┐
│  US  │◄──►│  EU  │◄──►│ APAC │
│Active│    │Active│    │Active│
└──┬───┘    └──┬───┘    └──┬───┘
   │           │           │
   └───────────┼───────────┘
               │
         Global Load Balancer
         routes by location
```

## Region Selection

### Selection Criteria

```text
Region Selection Factors:

1. User Location
   □ Where are your users?
   □ Latency requirements per region?
   □ User concentration (80/20 rule)?

2. Compliance Requirements
   □ Data residency laws (GDPR, etc.)
   □ Government regulations
   □ Industry requirements (HIPAA, PCI)

3. Cloud Provider Availability
   □ Not all services in all regions
   □ Service feature parity
   □ Regional pricing differences

4. Network Connectivity
   □ Internet exchange points
   □ Direct connect options
   □ Cross-region latency

5. Disaster Risk
   □ Natural disaster patterns
   □ Political stability
   □ Infrastructure reliability

6. Cost
   □ Compute/storage pricing varies
   □ Data transfer costs (egress)
   □ Support availability
```

### Common Region Pairs

```text
Region Pair Strategy:

Americas:
- Primary: US East (N. Virginia)
- Secondary: US West (Oregon) or US East (Ohio)
- Distance: 2,500-3,000 km
- Latency: ~60ms

Europe:
- Primary: EU West (Ireland)
- Secondary: EU Central (Frankfurt) or EU West (London)
- Distance: ~1,000-1,500 km
- Latency: ~20-30ms

Asia Pacific:
- Primary: Singapore or Tokyo
- Secondary: Sydney or Mumbai
- Distance: 5,000-7,000 km
- Latency: ~100-150ms

Global Triad:
- US East + EU West + Singapore/Tokyo
- Covers most global users
- <100ms to 80%+ of users
```

## Data Replication

### Replication Patterns

```text
Pattern 1: Async Replication (Most Common)
Primary ──────► Replica
         lag:
         ms to seconds

+ Lower latency for writes
+ Primary not blocked by replica
- Potential data loss on failover (RPO > 0)
- Replication lag visible

Pattern 2: Sync Replication
Primary ◄─────► Replica
         both
         confirm

+ No data loss on failover (RPO = 0)
+ Strong consistency
- Higher write latency
- Availability coupled to both regions

Pattern 3: Semi-Sync Replication
Primary ──────► At least 1 Replica (sync)
        └────► Other Replicas (async)

+ Guaranteed durability for some replicas
+ Balance of latency and durability
- More complex failure handling
```

### Conflict Resolution

```text
Multi-Primary Conflict Resolution:

Scenario: Same record updated in two regions simultaneously

Resolution Strategies:

1. Last Write Wins (LWW)
   └── Timestamp-based
   └── Simple but can lose data
   └── Clock sync important

2. First Write Wins
   └── First committed wins
   └── Later writes rejected or queued
   └── Good for "create once" data

3. Application-Level Resolution
   └── Custom merge logic
   └── Most flexible
   └── Most complex

4. CRDTs (Conflict-free Replicated Data Types)
   └── Mathematically guaranteed convergence
   └── Counters, sets, maps
   └── Good for specific use cases

Best Practice:
- Design to avoid conflicts where possible
- Partition data by region when appropriate
- Use single-primary for conflict-sensitive data
```

## Failover Strategies

### Failover Types

```text
Failover Types:

1. DNS-Based Failover
   ┌─────────────────────────────────────────┐
   │  DNS Health Check                       │
   │  ├── Check primary every 10-30s        │
   │  ├── 3 consecutive failures = unhealthy│
   │  └── Update DNS to point to secondary  │
   └─────────────────────────────────────────┘

   RTO: 60-300 seconds (DNS TTL + propagation)
   Pros: Simple, works with any app
   Cons: Slow failover, DNS caching issues

2. Load Balancer Failover
   ┌─────────────────────────────────────────┐
   │  Global Load Balancer                   │
   │  ├── Continuous health checks          │
   │  ├── Instant routing changes           │
   │  └── No DNS propagation wait           │
   └─────────────────────────────────────────┘

   RTO: 10-60 seconds
   Pros: Fast, reliable
   Cons: Requires GLB, potential single point

3. Application-Level Failover
   ┌─────────────────────────────────────────┐
   │  Client/App Aware                       │
   │  ├── Client retries to alternate region│
   │  ├── SDK handles failover              │
   │  └── No infrastructure dependency      │
   └─────────────────────────────────────────┘

   RTO: 1-10 seconds
   Pros: Fastest, most control
   Cons: Requires client changes
```

### RTO and RPO

```text
Recovery Objectives:

RTO (Recovery Time Objective):
└── Maximum acceptable downtime
└── Time from failure to recovery
└── Drives failover automation investment

RPO (Recovery Point Objective):
└── Maximum acceptable data loss
└── Time between last backup and failure
└── Drives replication strategy

Common Targets:
┌──────────────┬──────────┬──────────┬───────────────────┐
│ Tier         │ RTO      │ RPO      │ Strategy          │
├──────────────┼──────────┼──────────┼───────────────────┤
│ Critical     │ <1 min   │ 0        │ Active-active     │
│              │          │          │ Sync replication  │
├──────────────┼──────────┼──────────┼───────────────────┤
│ High         │ <15 min  │ <1 min   │ Active-passive    │
│              │          │          │ Hot standby       │
├──────────────┼──────────┼──────────┼───────────────────┤
│ Medium       │ <4 hours │ <1 hour  │ Warm standby      │
│              │          │          │ Async replication │
├──────────────┼──────────┼──────────┼───────────────────┤
│ Low          │ <24 hours│ <24 hours│ Backup/Restore