Running a database heavy webapp in the UK and Aus server setup

Question

I am running a webapp from a uk datacenter. Speed is fine as expected. The webapp relies heavily on a database. I would like to open the webapp to Australia and New Zealand but maintain good response time from the server.

Essentially the each user in the app has access to data stored in two tables in the db. Each user uses said data to generate their own combination of this data and store in other tables in the db. There are few asset updates to the app.

Registered emails would need to be unique in all countries.

From my limited knowledge in this area I believe there are two options: A - Full database replication between two hosts, one in the UK and one in AUS B - Periodic replication of data from a source host, the uk, to the targets, in aus and nz.

This then leaves the domain 1 - Ideally on domain would be best however this would need a routing server of sorts to direct traffic based on location to different servers, but this would increase response time 2 - Have alternate domains per country routing directly to the country local host

I appreciate I am not reinventing the wheel here but what is the std protocol for a scenario like this? A cdn service from my understanding here is more for image and video delivery, i suppose the base question here is what is the equivalent for databases?

Thanks for any help, John

Answer 1

You have several different issues here that would probably be better served as separate questions. The first is how you should architect your multi-site database structure. The second being how you route users to your servers.

For the database problem, something as simple as multi-master replication may be all you need. There is no easy answer to this as there are too many variables that need to be considered. The volume of data, the capabilities of the database server software, the reliability of the connection between the two sites, how much data actually needs to be shared between sites, if the data needs to be always exactly the same, or eventually the same..

For the second problem, a CDN may not be a good choice if your sites is almost completely dynamic. A CDN isn't for 'image and video delivery', it's primarily for static content delivery (image and videos being a subset of that, any web page that's not being served up dynamically, javascript files, css files, etc.) Many CDNs offer services that can speed up dynamic content as well through various tricks but that's not what you're after.

I'm aware of two main ways a CDN and large organizations can handle a situation like this. The first is through DNS, using some sort of mechanism to determine what IP address to return to a client. That may be based on the client's IP addres such as looking up in a geolocation database or another mechanism to determine what is best to direct the client to.

The second way is to use anycast. The idea here is that you announce the exact same IP addresses from multiple locations, and rely on standard internet routing to get you to a close site (close being relative to the network, not geography).

If you want my opinion, pick a location that has decent connectivity to the locations you'd like to serve. If you are only serving people in the UK and in New Zealand for example, a single location in the US may be good enough for both. I don't know what your application does, but if the few milliseconds difference is going to make a meaningful impact on your user you may want to rethink the design. From my desk at work in San Jose, CA it's less than a quarter of a second to both New Zealand and Australia (< 250ms).