A Global WordPress Site on the Multi-Region Cluster: Serving Three Continents from the Nearest Region, with Geo-DNS and Honest Trade-Offs

A CDN makes a WordPress site's static assets fast everywhere. It does not make the site itself fast everywhere: a reader in Singapore still waits for a London server to render the page, log them in or accept a comment. Serving a dynamic site from several regions is the next step, and it is a hard one, which is why the package that does it wears an alpha label. This post follows a DevOps engineer deploying the Multi-Region WordPress Cluster on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, and being candid about what it is.

The site is a travel publisher we will call Meridian Routes: a WordPress magazine with a membership area and comments, readers spread across North America, Europe and Asia-Pacific, and a London cluster that served them all. The Multi-Region WordPress Cluster deploys a complete WordPress cluster in each selected region and keeps them synchronised, so visitors are served from the nearest region and a whole-region outage does not take the site offline.

What the package builds in each region

In every region you select, the package installs a full WordPress cluster: a load balancer, PHP application servers and MariaDB, so each region can serve the entire site on its own. Across the regions it wires two things. Database replication between the regional MariaDB layers, in one of two topologies chosen at install. And file synchronisation for uploads, themes and plugins, so media published in London appears in Singapore, using a GlusterFS cluster as the fault-tolerant shared storage for static assets. Each region exposes its own entry point; routing readers to the nearest one is your job, with geo-DNS or a CDN that selects an origin by geography.

The database choice, and the 20 millisecond rule

The package offers two database topologies, and the platform's documentation is precise about when to use each. Async Primary-Replica Distribution (at least two regions): two interconnected primaries with asynchronous replication; the first region's primary takes reads and writes, the second's takes reads, and if the first fails the second starts accepting writes; further regions hold replicas. Recommended when reads dominate writes, when latency between regions exceeds a few tens of milliseconds, and when replication delay is tolerable. Sync Galera Distribution (at least three regions): one Galera cluster with a segment per region, true multi-primary, no lost transactions, recommended when every region needs the write instantly and inter-region latency is very low. The rule of thumb in the docs: under about 20 milliseconds ping between all regions, Galera; otherwise async.

Meridian's regions are New York, London and Singapore. Round trips are 70 to 200 milliseconds. The choice makes itself: async, with London as the first region because that is where the editors are, so publishing writes are local; New York and Singapore serve reads locally and replicate from London within a second or so. A reader in Singapore who posts a comment writes to London, 180 milliseconds away, once, and reads everything else from Singapore.

Routing readers: geo-DNS

Each regional cluster has a public IP on its load balancer. The engineer configures the publisher's DNS provider with geo-DNS: the site's hostname resolves to London's IP for European resolvers, New York's for the Americas, Singapore's for Asia-Pacific, with health checks at the DNS provider so a region that stops answering is removed from its geography and readers fall through to the next nearest. The Let's Encrypt add-on on each balancer holds a certificate for the same hostname, validated via DNS. A CDN in front for static assets remains, because a CDN edge is still closer than a region for images and scripts.

What the alpha label means, tested

The package's maintainers call the cross-region replication model young, and the engineer treats that as an instruction to test with the site's actual plugins and write patterns before believing anything. On a trial deployment she found what the label warns about. WordPress plugins that write on every page view, a view counter and a related-posts cache, generated writes from Singapore that each paid the round trip to London and, worse, created replication churn; she replaced the counter with the analytics tool the publisher already had and configured the cache plugin to store in each region's Redis rather than the database. Logged-in members' session handling worked, because sessions are cookies and user rows replicate. Comment posting worked with the expected 180 millisecond write. WooCommerce, which the publisher does not run, would have needed more thought, because a cart is a write on every action.

Her write-up for the publisher lists the plugins tested, the ones changed, and a rule for editors: publish from London, which they already do.

Failing a region, on purpose

She stopped the Singapore cluster from the dashboard. Geo-DNS's health check removed Singapore's IP within its check interval, and readers in Asia-Pacific resolved to London, slower but served. She restarted Singapore; its MariaDB replica caught up from London and DNS returned it to rotation. Then the harder one: London, the write region. New York's primary began accepting writes per the topology's design; editors were pointed at New York's admin for the duration; when London returned, its database was re-established as a replica of New York before being swapped back to the write role in a planned window. The runbook for that swap is the most important document the project produced.

Cost and result

Three clusters instead of one is roughly three times the compute, though each region's PHP layer scales to its own daytime, so the total is less than three times London's peak: about 150 cloudlets an hour across the three regions, roughly $365 a month before discounts at MassiveGRID's published $0.003372 per cloudlet-hour, plus three public IPs, GlusterFS disk and inter-region replication traffic. Page load in Singapore went from 1.8 seconds to under 0.5 for a reader's first byte from a nearby region. The publisher's editor put it differently: comments from Australian readers went up, because commenting stopped feeling slow.

Frequently Asked Questions

Is the Multi-Region WordPress Standalone package a cheaper way to do this?

Yes. It places single LiteSpeed WordPress instances in two regions, a primary and a replica, connected as one solution, for sites that need geographic redundancy without full clusters in each region. It is the right first step for smaller sites; the cluster package is for sites that already run clustered WordPress.

Which regions can I combine?

Any of MassiveGRID's four: New York, London, Frankfurt and Singapore, selected at install. The async database topology needs at least two; the Galera topology needs at least three and very low latency between them, which in practice means European regions.

How do editors know which region they are writing to?

With the async topology, writes go to the first region's primary; point the admin hostname (for example admin.yoursite) directly at that region's balancer rather than through geo-DNS, so editors always publish there and the failover runbook is the only time it changes.