Your service is running smoothly in a single data center. Then an earthquake hits, the power grid fails, or a fiber cable gets cut. Suddenly, millions of users cannot access your application.

This is not hypothetical. In 2017, an S3 outage in US-East-1 took down a significant portion of the internet. Companies relying solely on that region were completely offline for hours. In 2021, a BGP misconfiguration at Facebook took down WhatsApp, Instagram, and Facebook itself for six hours globally.

Multi-region architecture is how you survive these disasters. By deploying your application across multiple geographic regions, you eliminate single points of failure at the infrastructure level.

But going multi-region is not just about disaster recovery. It is also about latency. Physics is unforgiving: light through fiber travels at about 200,000 km/s, and a round trip from Tokyo to Virginia takes at least 150ms. A user in Tokyo should not have to wait that long for every request when you could serve them from a nearby region in 20ms.

The challenge is that multi-region is genuinely hard. Data needs to exist in multiple places simultaneously, which means dealing with replication lag, consistency trade-offs, and conflict resolution. Get it wrong, and you end up with corrupted data or a system that is slower than a single-region deployment.

In this chapter, we will cover the core patterns for multi-region architecture: why you might need it, the main architectural approaches, how to handle data replication, traffic routing strategies, failure handling, and how companies like Netflix and Uber implement these patterns in practice.

When interviewers ask "How would you make this globally available?" or "What happens if an entire region goes down?", they are probing for your understanding of multi-region strategies. The answer is never just "deploy in multiple regions." They want to know which pattern you would use, how you would handle data consistency, and what trade-offs you are making.

1. Why Go Multi-Region?