Multi-region architecture for new market expansion

When people talk about multi-region architecture, it’s often in the context of operational resilience. And that’s certainly a valid use case in a world where cloud region failures aren’t uncommon.

But resilience is not the only reason to consider multi-region architecture. Fast-growing companies should also consider the virtues of multi-cloud deployments for market expansion.

Easier regulatory compliance

As of 2021, more than 100 countries had laws on the books requiring that at least some of their citizens’ data be processed and/or stored in-country. Similar laws are in the works in many other countries. In some markets and industries, there are even data residency rules on a more local level – in the US, for example, the Wire Act requires companies that process bets to do so in the state where the bet was placed.

All of these regulations mean that multi-region is often the best option for companies that are looking to expand into new markets. Clicking an “add region” button and and spinning up a local node for your database, for example, is certainly easier and cheaper than creating a wholly separate copy of your application for each region (and then having to manage each region’s application separately, deal with data consistency issues across your various regional applications, etc.)

Of course, going multi-region isn’t always quite as easy as clicking a button – more on that shortly.

Lower latency

When expanding into a new geographic market, it’s important to ensure that your new customers aren’t getting a second-rate experience. But that’s precisely what can end up happening if your new customers in India (for example) have to wait for queries to travel to and from your database in America every time they try to use a feature.

For that reason, multi-region can be important for market expansions even when regulatory compliance isn’t a pressing concern. The further your new market is from your existing market geographically, the higher the latency penalty your users and customers will have to pay if either your application or database aren’t available locally.

And again, deploying a single application and database across multiple regions – if done properly – is easier, faster, and cheaper than trying to build and manage separate applications and/or databases for each market.

Lower costs

Because the alternative is building and managing something wholly separate locally, multi-region deployments often end up providing significant cost savings over the alternative.

Precisely how much a company will save depends on a lot of specifics, and going multi-region won’t necessarily offer a cost savings in 100% of cases. Generally though, in cases where data has to stay local (for regulatory reasons, latency reasons, or both), deploying your application and database across multiple cloud regions means significant savings in terms of management and ops – you’re still only managing one application and one database – when it’s done right.

The “done right” part is critical, though. Multi-region can get overly complex and overly expensive quickly if you’re using the wrong tools or haven’t thought things through.

Multi-region the “easy” way

First things first: multi-region is never easy. In fact, deploying and managing any kind of application at scale is never easy. There are challenges and complicating factors with every possible approach.

However, many of the largest challenges associated with multi-region can be avoided with proper planning and the right tools.

Generally speaking, the hardest part of going multi-region is the database. Application instances are pretty easy to add anywhere, but distributing the database can be a challenge because the data must generally remain consistent across all regions where it’s deployed. For tier 0 and tier 1 workloads, that consistency often has to be instant or near-instant – you don’t want a customer to be able to complete checkout with an item somebody in another region just bought, for example.

It’s very possible to build bespoke systems to handle this, manually sharding your database and writing a routing layer to ensure application instances send and receive data from the correct shards. But this approach is money- and labor-intensive, and will often require refactoring when the company needs to expand again.

The easier approach is simply to leverage databases that were built for the cloud – and built for multi-region and multi-cloud – from the ground up to solve these problems for you.

CockroachDB, for example, allows you to deploy a single database across multiple regions (or multiple clouds, or on-prem data centers and clouds, etc.) that handles the data routing and consistency problems for you. You don’t have to build anything. You don’t have to refactor your code. You simply send queries to the database just like you would a single-instance Postgres deployment, and CockroachDB routes them and manages consistency between all of your nodes, wherever they are in the world.

The net result of this is often significant cost savings. One multi-region CockroachDB customer, for example, estimates that it saves $1.5 million per state it expands into, because leveraging a multi-region CockroachDB deployment allows them to avoid making the 5-10 new hires they would otherwise need to handle the complexity associated with creating and managing a new database shard for each state in-house.

Find out how CockroachDB could make your regional expansions faster.