The master-sub architecture is simple to describe and deceptively complex to design well at scale. In principle, one site holds the authoritative user database and pushes changes to connected sub-sites. In practice, enterprise WordPress networks introduce constraints that this simple description does not capture: tens of thousands of users generating concurrent events, dozens of connected sub-sites with different performance characteristics, organizational requirements that may mandate multiple geographic masters, failover requirements that must not compromise data integrity, and compliance mandates that restrict which data can flow between which systems. Every one of these constraints becomes a design input that shapes the architecture.
Most documentation on WordPress user sync master-sub architecture is written for small networks: two or three sites, a few hundred users, a single master that is obviously the right choice. This guide is written for the other end of the spectrum: networks where the architecture decisions have real performance, reliability, and compliance consequences that are not visible until something goes wrong at scale — and at scale, things going wrong has immediate, visible, expensive consequences.
This guide covers every architectural decision point in a large-scale WordPress user network: master site selection and its criteria, topological models and their tradeoffs, event volume capacity planning, sub-site connection management, failover design, and the configuration choices that determine whether the network operates reliably at 10x current scale. We cover these in the context of how enterprise WordPress user sync with master-sub architecture is designed to handle these requirements.
This guide is written for senior WordPress architects, enterprise IT leads, and platform engineers who are responsible for user sync infrastructure at a scale where design decisions have material business impact. It assumes deep WordPress technical familiarity and comfort with distributed systems concepts.
Master site selection: the six criteria that determine the right choice
The master site is the center of gravity for the entire user sync network. Every design decision downstream from this choice is constrained by the capabilities and limitations of whatever site is designated as master. Getting this wrong is expensive to correct later — rearchitecting a live enterprise sync network to move the master is a major operational event. The following six criteria should be evaluated systematically before the master is designated.
Most critical criterion
The master site must be capable of handling the combined write load of all user events across the entire network, because every event that originates anywhere in the network ultimately creates a write operation on the master’s database. Measure the current peak concurrent database write throughput on candidate master sites under actual production load. At enterprise scale, the master needs headroom — not just sufficient capacity for current load but for 3x to 5x growth. A site running near its write capacity ceiling is wrong for the master role even if it is the logical organizational choice.
Scales with number of sub-sites
For each sync event, the master must make one outbound REST API call per connected sub-site. A network with 25 sub-sites means every user event generates 25 concurrent outbound HTTP requests from the master site. PHP’s default execution model processes these sequentially unless the implementation uses async or parallel HTTP. On a network with high event volume and many sub-sites, the master’s PHP process pool and the server’s outbound connection limits can become the bottleneck. Measure and plan for peak concurrent outbound connections — max_connections in your web server configuration is the ceiling.
Master downtime = network-wide sync halt
When the master site is unavailable, the entire sync network stops. Sub-sites continue to function — users can still log in, purchase, and update profiles — but none of those events are propagated until the master recovers. The master’s hosting SLA directly determines the maximum acceptable sync outage frequency for the entire network. For enterprise networks, the master should be hosted on infrastructure with a 99.9% or better uptime SLA, redundant database configuration, and a failover or recovery procedure that is tested and documented.
Latency impacts queue throughput
The master site’s geographic location relative to the sub-sites it serves affects the latency of each API call during sync delivery. A master hosted in Frankfurt delivering sync to sub-sites in Singapore and São Paulo will have API call latency in the hundreds of milliseconds per call. Across a high-volume event queue, this latency accumulates into meaningful throughput reduction. In enterprise networks spanning multiple continents, geographic proximity is a criterion that may favor a hierarchical or regional hub topology over a flat single-master topology.
May mandate master location
Data residency regulations in certain jurisdictions — GDPR in the EU, PDPA in Thailand, PIPEDA in Canada, China’s Cybersecurity Law — may require that the authoritative user database for users in that jurisdiction is hosted within it. If your largest user base is in the EU and EU regulations require EU-hosted user data, the master must be hosted in an EU data center regardless of where the organization’s operational hub is located. Data residency requirements should be the first constraint evaluated before any performance or organizational criteria.
Often overlooked — critical for enterprise
The master site will receive plugin updates, theme updates, hosting changes, and configuration changes more frequently than any other site in the network, because all the most important things run there. Uncoordinated changes to the master — a plugin update that introduces a conflict with the sync plugin, a hosting migration that changes the server environment, a PHP version upgrade that changes behavior — can break the entire network’s sync simultaneously. The master site must be managed under the most rigorous change management process in the organization. If the organizational team managing the candidate master site does not have this maturity, it is the wrong choice for master regardless of its technical characteristics.
Four topological models: choosing the right network structure for your scale
The topology of a WordPress user sync network — the pattern of how sites connect to each other — determines the maximum achievable throughput, the geographic distribution of latency, the impact radius of any single site failure, and the operational complexity of day-to-day management. Enterprise networks have four meaningful topological options, each with distinct characteristics that make it appropriate for specific scale and complexity profiles.
All sub-sites connect directly to a single master. Every sync event flows from the master to each connected sub-site via a direct API call. Every sub-site registration or update event triggers a write to the master, which then distributes to all other sub-sites. Simple to configure, simple to monitor, simple to troubleshoot. The master is the single point of authority and the single point of failure.
A global master distributes to a set of regional hub sites. Each regional hub distributes to the sub-sites within its region. The global master’s outbound API call count equals the number of regional hubs rather than the total number of leaf sub-sites. Distribution load is shared across the regional hubs. A sub-site registration propagates up to the regional hub, then to the global master, which distributes back down through all regional hubs to all other sub-sites. This is the topology used by franchise networks, regional enterprise deployments, and multi-campus academic institutions.
Two or more sites can initiate user events that are treated as authoritative within their defined scope. A North American master handles all NA user events authoritatively. A European master handles EU user events authoritatively. Both synchronize with each other on a schedule or in real time, with explicit conflict resolution rules for cases where the same user is updated on both masters within the conflict window. This topology is motivated by data residency requirements that prevent EU user data from being processed on non-EU infrastructure, or by organizational autonomy requirements that give regional entities control over their user populations.
Each site in the network maintains complete autonomy over its own user database. A dedicated identity broker — either a WordPress installation configured purely as an identity service, or an external identity provider — maintains a minimal shared identity record for each user (typically just a globally unique identifier, email, and basic profile). Individual sites authenticate against the broker for SSO purposes but maintain their own local user records independently. Data sync between sites is minimal and limited to identity-layer fields; site-specific data never leaves the originating site.
Event volume capacity planning: calculating throughput requirements before they bite you
The most common enterprise sync architecture failure mode is not a configuration error or a code bug — it is a capacity shortfall that was never calculated in advance. The system works fine at current scale, the queue processes events in near-real-time, and nobody thinks about capacity until a product launch or a marketing campaign drives a registration spike that overwhelms the queue processor. By the time the problem is visible, the backlog has accumulated for hours.
Capacity planning for a user sync queue requires calculating three numbers: the expected peak event rate, the queue processor throughput per minute, and the maximum acceptable queue depth. If peak event rate exceeds processor throughput, the queue grows. If it grows long enough to exceed the maximum acceptable depth, the lag between an event occurring and being delivered to sub-sites becomes operationally significant.
// Variables for capacity calculation peak_registrations_per_hour = estimated peak new users/hr profile_updates_per_active_user = avg updates per active user per day daily_active_users = your DAU figure sub_site_count = number of connected sub-sites avg_api_call_duration_ms = measured round-trip to each sub-site // Events per hour at peak peak_events_per_hour = peak_registrations_per_hour + (daily_active_users × profile_updates_per_active_user / 24) // API calls required per hour at peak peak_api_calls_per_hour = peak_events_per_hour × sub_site_count // Queue processor throughput (events/min, batch processing) events_per_minute = (60,000ms / avg_api_call_duration_ms) / sub_site_count // Required batch frequency to stay current required_batch_cycles_per_minute = peak_events_per_hour / 60 / events_per_minute
The critical output from this calculation is whether the queue processor can clear events faster than they arrive at peak load. If required_batch_cycles_per_minute exceeds 1, the queue will accumulate during peak periods. How much this matters depends on your acceptable lag — for SSO and login-related events, a 5-minute lag is acceptable. For role changes that affect access, it may not be.
The levers available to increase throughput are: increasing the cron frequency (system cron rather than WordPress pseudo-cron enables sub-minute scheduling), increasing the batch size per cycle, reducing average API call duration by improving sub-site response times, or distributing load across multiple master processes if the sync plugin architecture supports it. For hierarchical topologies, distributing events across regional hubs is the architectural mechanism for horizontal scaling.
Connection management at scale: the operational complexity of 20+ sub-sites
Managing a sync network with a handful of sub-sites is simple enough to handle informally. Managing one with 20 or more sub-sites requires systematic connection management processes — because the consequences of an undocumented, misconfigured, or expired connection are not obvious until a subset of users starts experiencing access problems, and the investigation time required to identify which connection is at fault is proportional to how well the connections are documented.
Maintain a centralized connection registry that records: sub-site domain and URL, connection establishment date, last key rotation date, responsible team/department, sync scope configured for this connection, role mapping in effect, and the current sync health status. This registry is your primary diagnostic reference during incidents. In a flat single-master topology with 25 sub-sites, identifying the one connection that is failing should take 30 seconds with a registry, not 30 minutes without one.
Enterprise security policies typically require API credentials to be rotated on a defined schedule — annually at minimum for most frameworks, quarterly for high-compliance environments. With 25 sub-site connections, uncoordinated key rotation creates the constant risk that a connection is using expired credentials. Implement a scheduled rotation calendar and a documented procedure that ensures both sides of each connection are updated atomically. A key rotation that updates the master but not the sub-site, or vice versa, breaks the connection until manually corrected.
When a sub-site is retired, decommissioned, or migrated to a new domain, the corresponding connection on the master must be explicitly removed and its connection keys invalidated. Orphaned connections — master-side connection configurations for sub-sites that no longer exist or have changed domains — generate consistent failure events in the sync log that mask real problems and create alert fatigue. Decommissioning a sub-site should include a formal connection cleanup step on the master as a required part of the offboarding procedure.
Failover design: protecting data integrity when the master goes down
Master site unavailability is not a theoretical edge case in a network that operates for years at enterprise scale. Planned maintenance windows, unplanned hosting incidents, database failures, DDoS events, and DNS propagation delays all create periods during which the master cannot process events. How the architecture handles these periods determines whether the network recovers cleanly or accumulates data integrity problems that require manual remediation.
Events that occur on sub-sites during master downtime must be queued locally on each sub-site and held until the master recovers. This requires sub-sites to have their own local event queue for outbound events, not just for inbound delivery. When the master recovers, each sub-site flushes its local queue to the master in chronological order. The master then reprocesses and distributes the accumulated events. Verify that your sync plugin implements local event queuing on sub-sites — not all implementations do this, and those that do not lose events generated during master downtime.
Before a planned master maintenance window, take a database backup that will serve as your recovery baseline. After the maintenance window, the first operation should be a queue health check — verify that no events are stuck, that the last-processed timestamp reflects the post-maintenance period, and that all sub-site connections are healthy. For extended maintenance windows (over an hour), consider running a targeted Bulk Push for users who registered or updated during the window to ensure their current state is distributed before they encounter any access issues.
For enterprise networks where master downtime is genuinely unacceptable, the master site’s database can be configured with a read replica that is promoted to primary if the master database fails. This is a hosting-level configuration — MySQL replication, Amazon RDS Multi-AZ, or similar managed database redundancy — not a WordPress-level configuration. The sync plugin continues operating against the WordPress application layer; the failover happens transparently at the database level. This architecture eliminates database failure as a master downtime cause, though it does not protect against application-level failures.
Enterprise architecture decision matrix
Combining the criteria and topological options described above, the following matrix provides a reference for matching your enterprise context to the appropriate architecture.
Enterprise WordPress user network architecture is one of the areas where thoughtful upfront design pays dividends for years and architectural shortcuts create compounding problems that become progressively more expensive to correct. The decisions covered in this guide — master selection, topology, capacity planning, connection management, failover, and compliance — are not independently complex. The complexity comes from their interaction: a topology that looks right for the current scale may be wrong for the projected scale in eighteen months, and re-architecting under load is significantly harder than getting it right initially.
Nexu User Sync’s enterprise WordPress master-sub architecture for large-scale user networks provides the connection management, configurable batch processing, queue depth monitoring, per-connection scope control, and event logging infrastructure that enterprise network design requires. The architectural decisions described in this guide are yours to make. The infrastructure to execute them reliably is built in.
The infrastructure that enterprise WordPress user network architecture demands.
Nexu User Sync provides the connection management, configurable throughput controls, queue depth visibility, per-connection metadata scope, and event audit log that enterprise-scale WordPress user networks require to operate reliably at any topology.
Just wanted to share my experience with this architecture guide. As someone managing a network with over 20 sub sites, I was really worried about how we'd handle the sheer volume of concurrent user events without everything grinding to a halt.
I'm testing this out for a client with a pretty busy network, and I had a question about latency. The guide says sync events go through direct API calls, which totally makes sense, but when you're dealing with a ton of events in the queue, that latency starts adding up and can really slow things down. any tips on how to handle that in real world setups? We're looking at 50k+ users with lots of updates happening all the time
Saved my butt in rush hour.
Hey, saved me from a huge mistake!