Skip to main content

Why Build a Multi Region Application | Fault Tolerance | Low Latency | Data Privacy

In this video Meagan Goldman from Cockroach Labs explains the Top 5 reasons why you should build #MultiRegion applications. 00:00 Introduction 00:15 What is a multi-region application 00:30 How multi-region applications increase fault tolerance 1:19 Low Latency in multi-region applications 2:00 Increasing user-base with multi-region applications 2:58 Scaling multi-region applications 3:24 Using multi-region applications to comply with data privacy laws and regulations 3:53 Top 5 reasons to build a multi-region application #1. How Multi-Region Application Architecture makes apps Fault Tolerant: • #FaultTolerance is the ability of a system to endure a failure of some kind and continue to operate properly. • The unfortunate reality is that failures happen. A fire, a flood, or an extreme storm can take out a data center, an availability zone, or an entire region. But that doesn’t have to result in an outage. • Multi-region applications are resilient in a way that single region and single availability zone applications are not. Single region architecture can survive machine failures. Single availability zone architecture can survive an AZ failure. But only a multi-region application architecture can survive a region failure. • If your application has #HighAvailability requirements then multi-region architecture is important. #2. How Multi-Region Application Architecture delivers Low Latency • How does a multi-region application architecture help with #LowLatency? In short, it allows you to keep data close to users. • Consider an example: Imagine your business has users in New York City and Sydney, Australia. If you just deploy your application in a data center near New York, then users in Sydney will experience high latencies. They have to wait while their requests travel all the way to New York and back. But if you deploy your applications in multiple regions, and you put another data center closer to Sydney, then the client request time will dramatically improve. • A good rule of thumb is to keep latencies under 100 milliseconds. That is the maximum threshold for an experience to feel instantaneous. When a user base is spread out all over the world it’s challenging to keep latencies under 100 ms because the data is limited by the speed of light. • The only way to achieve low latency, and great user experiences, is to keep the data close to the users with multi-region application architecture. #3. Grow a user base with multi-region applications • Some organizations prefer to gain a meaningful quantity of users in a new region before adding a database in that region. There is a risk to this strategy. If your only data centers are in US-East then you’re most likely serving users in Sydney a high latency experience. If those users are having bad experiences then your application is unlikely to grow. • Other companies take the opposite approach. A good example would be the online sports gambling companies from Europe that chose to add data centers in the United States as soon as gambling became legal in some US states. These businesses saw the potential to gain new users and then scaled their application architecture to that new region to make sure the new users would have a good experience. #4. Application architecture flexibility • #DatabaseSchema: When you design a schema for multi-region architecture, you need to partition your database, which requires identifying a column to partition on, actually partitioning the database on that column, and then setting up zone constraints. If you do that once, it's a much lower lift to just add new regions with ALTER statements. • Cloud deployments: You have your database and your application deployed in multiple servers, across multiple regions. Most cloud providers make it easy to just add another regional server. Then you just need to deploy the database and app to that server. It's also likely the case that you have used docker and a kubernetes engine to deploy the database and the app, which means you’ve written some docker and kubernetes deployment configuration files. With these already written, you simply use them to deploy to a new region. This is much easier than writing the files from scratch. • Application logic: You've already written the application to filter queries on partitions, and possibly to be aware of user locations. This means you don't have to edit the application very much in an expansion to a new region. #5. Comply with #DataPrivacy Laws & Regulations With the right multi-region deployment, you can keep data where it legally needs to be, by pinning data within the boundaries of a physical location. Helpful links: Resource: Resource: Docs: Resource: