Geo-Distributed APIs & Disaster Recovery

In this lesson, we'll explore how to design APIs that span multiple geographical regions. This approach, known as geo-distribution, is crucial for achieving high availability and low latency for a global user base.

We'll also dive into Disaster Recovery (DR) strategies, which are plans to ensure your API remains operational or recovers quickly after significant outages.

Deploying your API in multiple regions offers two main benefits:

• Reduced Latency: Users connect to the closest server, minimizing network travel time.
• Enhanced Resilience: If one region fails, traffic can be routed to another, preventing a total outage.

This provides a better experience and stronger reliability.

An Active-Active geo-distribution strategy means your API is fully operational in multiple regions simultaneously. All regions handle user traffic.

• Pros: Highest availability, lowest latency, no manual failover needed.
• Cons: Complex data synchronization across regions, potential for data conflicts.

In an Active-Passive setup, one region is active and serves all traffic, while other regions are on standby. If the active region fails, traffic is manually or automatically switched to a passive region.

• Pros: Simpler data management (only one write region usually), easier to set up.
• Cons: Higher Recovery Time Objective (RTO) during failover, potential data loss (higher RPO).

To direct users to the correct region, you need a global traffic router. DNS-based routing is common, using services like AWS Route 53 or Azure Traffic Manager.

These services can route traffic based on:

• Latency: Send users to the region with the lowest network latency.
• Geolocation: Send users to a specific region based on their geographical location.
• Health Checks: Only send traffic to healthy, operational regions.

A major challenge in geo-distributed APIs is replicating data across regions. This involves ensuring data consistency and handling potential conflicts.

• Eventual Consistency: Data eventually becomes consistent across all regions, but there might be a delay.
• Multi-Master Databases: Allow writes in multiple regions, but require robust conflict resolution.
• Read Replicas: Read-heavy applications can use replicas in other regions for low-latency reads.

Disaster Recovery (DR) is a plan to recover from a major outage that impacts an entire region or critical infrastructure. Key metrics for DR are:

• Recovery Time Objective (RTO): The maximum acceptable downtime.
• Recovery Point Objective (RPO): The maximum acceptable data loss.

Lower RTO and RPO usually mean higher cost and complexity.

The simplest DR approach is Backup and Restore. Data is regularly backed up to another region, and in a disaster, a new environment is spun up and data is restored.

• Pros: Low cost, relatively simple to implement.
• Cons: High RTO (can take hours or days), high RPO (data loss since last backup).

Suitable for non-critical systems.

The Pilot Light strategy keeps a minimal, core set of resources (like databases) running in the DR region. In a disaster, you spin up the rest of the application components.

• Pros: Lower RTO than Backup & Restore, lower cost than Warm Standby.
• Cons: Still requires some time to fully recover, higher RPO than Warm Standby.

Consider an API that processes critical financial transactions. Which disaster recovery strategy would typically offer the lowest Recovery Time Objective (RTO) and Recovery Point Objective (RPO)?

We've explored geo-distributed APIs, which enhance resilience and reduce latency by deploying services across regions. We learned about Active-Active (high availability, complex data) and Active-Passive (simpler, higher RTO) models.

We also covered Disaster Recovery (DR), defining RTO and RPO. Strategies discussed included Backup and Restore, Pilot Light, and Warm Standby, each offering different trade-offs in recovery speed and cost.