3

I am looking to create a multi-geographic infrastructure. Essentially, I need to serve a website to US, EU and AU users.

The challenge is that this website is ecommerce in nature, so needs read & write access on the database.

To my knowledge there are a number of options:

  1. Have a single RDS instance (multi AZ) in a central data centre (probably EU). Have multiple EC2 in each territory, which connect to the RDS.

  2. Have a complete environment in each territory (separate RDS and EC2, not connected to the others in any way). Live with the fact that user's can't share logins/data across territories.

  3. Have EC2s running MySQL in each territory. Build something into the application layer to handle syncing between the databases as writes happen.

  4. Have a central RDS that houses all data. Have child RDS instances in each territory that houses all read-only data (product data primarily). Build something into the application layer so that product-specific queries happen in the local database, but writes happen in the central RDS instance.

At the moment option #1 seems the most sensible, but I'm unsure of the actual latency between data centres, and I'm unable to source any reliable information on it.

No. 2 is limiting, but a possibility.

No. 3 is full of potential issues with syncing not working as expected.

No. 4 is possible but will require substantial refactoring of the application layer, which could in itself lead to issues.

What is the best approach here? Am I missing options? Is the latency between data centres 'acceptable'?

3

Options

Option 2 can't be made reliable on a single URL as it would rely on geolocation. Geolocation won't reliably select the same server for a given user over time. For this you'd need different URLs for each region.

You've missed a number of options:

  1. Use a central RDS instance for writes, with read replicas in each region.
  2. Use MySQL built in replication, rather than AWS features. I don't know if you can do this with RDS - I suspect you'd have to run MySQL on EC2. This is similar to #4, but not quite the same.
  3. Have a single EC2 instance / cluster and RDS instance. Accelerate the application using a content distribution such as CloudFront.

Option Analysis

I would always go with the simplest option first, which in this case is EC2 and RDS in the same location, using a CDN to increase performance. You haven't said why you think you need multiple application servers in different regions, so I'm puzzled why you've jumped straight to relatively complex options.

If a single location doesn't meet performance needs you could consider putting application servers in each region with a single RDS database. This might be faster, it depends on your application behaviour. You'd have to benchmark.

Only then would I consider the additional complexity of multiple databases.

Read Replicas

If you have control over the application I would build in the capability to have different database URLS for reading and writing from the beginning. This lets you move to read replicas later if you need to.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.