A multi-region WordPress cluster for a retail group
Fourteen brand sites consolidated into one cluster: TTFB down from 1.4s to 180ms, ready for an 8× traffic spike on 11.11.
- Client
- Retail group · Thailand
- Role
- Architecture lead & implementation
- Timeline
- 14 weeks
- Stack
- LiteSpeed ADC, MariaDB Galera, Redis
180ms
average TTFB
99.99%
uptime over 12 months
6×
capacity gained
14
sites consolidated
01 — The challenge
Each brand ran its own WordPress site on separate hosting. Patching lagged, analytics never matched, and costs sprawled. Twice a year a campaign knocked the sites over.
02 — Approach
Consolidated onto a central cluster: LiteSpeed Web ADC, a three-node MariaDB Galera, Redis object cache and shared block storage, fronted by a CDN with HTTP/3 and layer-7 WAF. Migrated site by site with regression tests.
03 — Outcome
The 11.11 campaign ran with zero downtime, server footprint dropped 6× for the same traffic, and IT ships weekly updates instead of monthly.
Stack
Starting point
Fourteen brand sites, nine hosting providers, PHP from 7.4 to 8.2, no usable staging, and three competing cache plugins on some sites.
The new architecture
CDN (HTTP/3 + WAF)
└─ LiteSpeed ADC (active/active, 2 nodes)
├─ Web node A (LiteSpeed Enterprise + LSCache)
├─ Web node B
└─ Web node C
├─ Redis (object cache, replicated)
├─ MariaDB Galera (3 nodes, multi-region)
└─ Shared block storage (wp-content)The migration plan that worked
- Stand up an empty cluster; rehearse with two pilot sites for two weeks.
- Move the lowest-traffic site first to prove the runbook.
- Use a 60-second DNS TTL and dual-run during cutover.
- Run the Playwright checkout flow after every deploy.
- Move the flagship brand last, on a Tuesday night.
Lessons
- High-latency shared storage is the real enemy — measure before choosing a provider.
- Never trust a health check that only tests TCP.
- A runbook is good only when someone else can follow it.