In my experience as a software engineer (and generally as a human, come to think of it), it seems to be universally easier to go from 2 to 3 of something, than it is to go from 1 to 2. For example, if your application already supports 2 languages, adding a 3rd is simple; whereas, if your application only supports 1 language, you need to build support for internationalization, before you can add the 2nd.
The same holds true for application architecture; adding a 3rd region to an application that’s already distributed and supports multiple regions is much easier than making a single region application distributed (can run across multiple machines) and then multi-region (region/locality awareness).
The Various Ways You Can Go Global 
Designing something that can run around the world is something that needs careful planning and involves trade-offs that need to be understood and accepted. I’d like to walk you through a couple of examples where a single-region application can be made multi-region, and the trade-offs that need to be addressed. I’m inventing some terms here, so no need to Google!
Disparate Regions
The first option you might consider would be to clone your application and database to additional regions as your business scales into those regions. Each regional deployment would exist in isolation, would not communicate with the other regions directly, and would require separate maintenance.
This architecture requires separate maintenance for each region. If 1 region takes 1 hour to update, it’ll take as many hours as you have regions to roll out a single update (and any downtime that incurs). Imagine a critical application bug or security patch and an estate of 24 disparate regions, and you get an idea as to how badly this architecture scales. There’s also a much more insidious, hidden cost associated with this architecture, and that’s “config drift”. Over time, small changes to each region to cater for region-specific requirements, will result in entirely separate, non-reconcilable applications. I’ve seen this first-hand and it’s a real headache.
Operational issues aside, this architecture also requires careful planning when it comes to Business Intelligence (BI). How do you identify global market trends and opportunities, when none of your databases share data? You’ll need to invest in an additional solution to collate the data and start putting it to work.
Stateless Multi-Region
The second option might involve bringing just the stateless parts of your application closer to your users; leaving the database in a single region.
This architecture has the benefit of simplifying your application and database deployments, at the cost of high latency reads and writes to applications that are not colocated with the database. The insidious, hidden cost in this architecture? You might be breaking the law by inadvertently pinning data to a region where it might not legally be allowed to exist for some of your application’s users.
True Multi-Region
The third option you might consider would be to deploy a single, logical instance of both your application and your database across multiple regions.
This architecture provides a bunch of benefits. Firstly, there’s only a single database and application to maintain, which is a huge operational burden lifted. Secondly - in CockroachDB’s case - data can be configured to reside anywhere you need it to, meaning fast reads and writes (depending on your table topology requirements), and regulatory compliance across all countries you operate.
In Conclusion
Running an application at global scale can be complex and expensive both from a CapEx and OpEx perspective. Centralizing the challenge of operating a global application by deploying truly multi-region architecture, can be an effective way to keep both costs under control.l
Centralizing your architecture also means eliminating the chance for config drift to creep into your architecture. This reduces the operational maintenance burden of your estate, along with the possibility for obscure bugs to affect your application’s reliability.
Operating one global system, results in a run-once update procedure. To update your entire application and database, only a single update effort is required. Not only does this take less time than performing multiple, separate updates, it’s also less error-prone.
One final point to mention about global architecture is the flexibility and repeatability it gives you. No longer do you have to maintain disparate regions and applications separately; a change that results in compliance in one locality, will likely be very similar to a change that results in compliance in another.
