Store in multiple geographical locations

Question

I am interested in setting up a store which has presence in multiple geographical locations (NA, EMEA, APAC). The reason for this is obviously to reduce the latency for end-users, at least while browsing and looking at products, I am fine with higher latency when it comes to placing an order etc.

FPC, CDN is already in use, but that obviously does not solve the latency problem.

Considering secondary regions will not be performing any admin tasks, the only shared state between the regions is the database and the media files. Media files I've already solved using GlusterFS geo-replication but I am struggling with the database.

I was able to come up with the following options as general solutions to the problem:

1. Setup a completely independant store per region.
2. Having a MySQL replica in the secondary region, doing reads locally, writes across the pond.
3. Having clustered multi-master MySQL (Galera/Percona)
4. Varnish caches across the pond (disabling caching when the user adds something to basket, etc).

Issues with #1:

1. Management. All the stores would have the same products, so modifying descriptions, stock etc would be a pain.
2. Integrating with external providers. If for example the store uses some third-party provider which deals with uploading listings in Amazon, eBay etc, they might not even support this sort of setup (adjusting stock in multiple stores as the purchase is made).

Issues with #2:

1. Magento already provides read/write splitting, but it seems that even when using FPC, and disabling visitor tracking, Magento still connects to the write side of the database to check for index locks which basically brings the performance down to the level as if it was served from across the pond. Even if I patch out the code which checks for index locks, it still tries to establish a connection to the write database for some reason. Given no writes are happening, if I set the write database to be the read only database, the performance becomes acceptable.

Issues with #3:

1. I assume that it will suffer from even worse issues than #2, just because every transaction has to be confirmed by every region, causing all of the regions to have latency, rather than just the secondary ones.

Issues with #4:

1. Invalidation. I am yet to discover a reasonable solution which is able to invalidate Varnish caches upon stock levels dropping to 0, staff making adjustments to descriptions, etc.

My questions:

1. Are you aware of any other solutions to the problem?
2. Do you have any experience using the options I provided above, the problems you've encountered, and ways you solved them (if you managed to)?

Answer 1

It is very cool question for Magento. I love this kind of ones.

So first of all, never split database across regions, it will introduce more problems than benefits for you!

If you want to deal only with latency you need only to create a fast access frontend for your end clients, not for the whole application stack.

1. You also don't need to flush cache as soon as your customer adds something to cart, you can use a smart hole punching of dynamic page parts, like shopping cart or compare list. It takes me usually only 1 day to make a webstore full varnish ready with my Varnish extension, you can try it out, it is available for free: https://github.com/EcomDev/EcomDev_Varnish/. It requires only adding two new layout handles to enable this kind of dynamic hole punching for existing theme. Also it has out of the box cache invalidation in place, you can add all your varnish server for ban requests to purge pages by product id or category id.

2. The best option would be to use Fastly as your CDN and frontend caching service, as it might help you in minimizing your infrastructure cost and leveraging maximum from their distributed network.

3. You might consider creating a separate microservice for session management, but that will require some skills in own socket server writing in PHP. However it would allow to create much more efficient shared session data retrieval for your Varnish cache backed frontend.