Geographic Distribution

On March 2, 2017, a typo in an Amazon engineer's command brought down a significant portion of S3 in the us-east-1 region. Websites, apps, and services across the internet went dark. But companies that had distributed their data geographically, keeping copies in us-west-2, eu-west-1, or other regions, kept running. Their users in those regions barely noticed.

Geographic distribution isn't just about performance (though getting data closer to users is a massive latency win). It's about survival. Earthquakes, power grid failures, fiber cuts, data center fires, these are real events that take out entire regions. If all your data lives in one building, one disaster can end your business.

Every major cloud provider has been evangelizing multi-region for years. AWS has 33 regions. Google Cloud has 40. Azure has 60+. They're not building all those data centers for fun, they're building them because their customers learned (sometimes the hard way) that geographic distribution is a requirement, not a nice-to-have.

Geographic distribution isn't binary, there's a spectrum:

Single region, multiple availability zones. Your data is in one geographic area (say, US East) but replicated across physically separate data centers (us-east-1a, us-east-1b, us-east-1c) within that region. Each AZ has independent power, cooling, and networking. This protects against single data center failures but not regional disasters.

Multi-region, single primary. One region handles writes, others have read replicas. Users everywhere get fast reads from their local region, but writes are slower for users far from the primary. This is the most common first step toward geographic distribution.

Multi-region, multi-primary. Multiple regions accept writes. Users write to their nearest region. Changes replicate across regions. This gives the best user experience but introduces conflict resolution complexity.