Multi-region deployment is proposed for two different reasons that need separating, because they have different solutions. One is latency: users far from your servers experience slow responses. The other is availability: you want to survive an entire region failing. Conflating them produces architectures that are expensive, complex, and no more reliable than what they replaced.
Take latency first, because it is usually solvable without moving anything. Most perceived slowness for distant users is not database round trips - it is images, JavaScript, CSS and fonts, all of which a CDN serves from an edge near the user for very little money. Add edge caching for read-heavy API responses and you have addressed the majority of the experience gap. If your servers are in Mumbai and your users are in Europe, a CDN typically fixes more than a second region would.
What a CDN cannot fix is a write, or a read that must be current. If your European users are submitting forms and every submission crosses to Mumbai and back, they feel it. That is the case where regional application servers genuinely help - and immediately raises the question that determines everything: what happens to the database.
There are only a few honest answers. A single primary with read replicas in other regions gives fast local reads and writes that still cross the ocean, which suits read-heavy applications and is by far the simplest to reason about. Sharding by geography - European users' data lives in Europe - gives fast reads and writes for everyone and works when users rarely need each other's data, which is common in B2B and rare in social products. Multi-primary with conflict resolution gives you both and asks you to decide what happens when two regions write the same record at once. That is a genuine distributed-systems problem, not a configuration setting.
For availability, be clear-eyed about what you are buying. Active-passive with a warm standby is straightforward and its risk is that the failover path is rehearsed rarely and therefore does not work when needed. Active-active is genuinely resilient and doubles your operational surface: every deployment, migration and configuration change now happens twice and must be safe in both orders. Teams frequently find that the added complexity causes more incidents than the regional outage it protects against - full region failures are rare, and self-inflicted ones are not.
The question worth answering before committing: what is the actual cost of an hour of regional outage to this business, and how does that compare with the permanent engineering cost of running two regions correctly? For most companies the answer favours one region done well - good backups, rehearsed restores, a CDN, and multi-zone within the region - over two regions run tiredly.
