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'?

mikemike
  • 131
  • 4

1 Answers1

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.

Tim
  • 31,888
  • 7
  • 52
  • 78