More than one region, and why you might not want it

Reading from a nearby replica is a well-worn pattern and mostly a configuration exercise, with the replication lag consequences from the reads lesson. Writing in two regions is a genuinely different system: either you coordinate every write across an ocean and accept the latency, or you accept conflicting writes and need a resolution strategy: last-writer-wins, CRDTs, or per-region ownership of a partition. There is no third option, and the choice affects your data model, not just your infrastructure.

Failover is also less automatic than the diagram suggests. Promoting a replica risks losing recently acknowledged writes, DNS and connection pools take time to notice, and the failback afterwards is the part nobody rehearses. An untested failover is a hypothesis. Teams that run one deliberately, on a quiet Tuesday, find out which of their assumptions were decorative.

The honest default for most products is one region chosen near the majority of users, a CDN for everything cacheable, and the money saved spent on making the single region reliable. Multi-region is a real answer to real requirements: regulatory data residency, a genuinely global user base, an availability target that a single region cannot meet, and a very expensive answer to a requirement nobody wrote down.