Scaling WordPress to Handle 10,000+ Concurrent Users

The Problem

I've worked on two WordPress scaling projects with similar challenges but very different traffic patterns:

Client A was a marketing agency with 11 mission-critical WordPress sites hosted together on a single VPS. Three of these sites received extremely high traffic. Their developers needed infrastructure-as-code workflows while content teams continued using WordPress admin normally.

Client B had an employee eCommerce store for a large corporation. Normally it had zero traffic. But when the company sent out emails offering store credit for merchandise, the site went from 0 to 10,000+ concurrent users within 60 seconds. The previous infrastructure completely failed during every promotional event—lost sales, frustrated employees, and embarrassed IT teams.

Why WordPress Doesn't "Just Scale"

WordPress was designed as a single-server application. Several components break when you try to put it behind a load balancer:

Challenge 1: The Media Library

WordPress stores uploaded files in wp-content/uploads/. In a load-balanced environment, a file uploaded via Server A wouldn't exist on Server B. Users would see intermittent broken images depending on which server handled their request.

Solution: Implement S3-compatible object storage using a plugin like WP Offload Media. All media files go to a centralized S3 bucket that all servers share. This also enables CDN integration—significantly improving load times and reducing bandwidth costs (CDN bandwidth is typically much cheaper than VPS egress).

Challenge 2: The Database

Traditional WordPress runs MySQL locally. You can't have each load-balanced server running its own database.

For most projects, I recommend managed databases (AWS RDS, DigitalOcean Managed MySQL, etc.)—they handle backups, scaling, and maintenance automatically.

However, Client A had security requirements for private data management. I set up a dedicated MySQL VPS server and built a custom PHP CLI backup tool:

# Available commands
php cli db:export      # Dump current database
php cli db:upload      # Upload backup to S3
php cli db:list        # List backups on S3
php cli db:download    # Retrieve backup from S3
php cli db:import      # Import with domain normalization
php cli db:backup      # Export + upload (runs on cron)
php cli db:restore     # Download + import for recovery

The Domain Normalization Problem

WordPress serializes data throughout the database and stores domain references in that serialized data. A simple find-replace breaks the serialization. You can't just UPDATE wp_options SET option_value = REPLACE(...).

The solution uses WP-CLI's search-replace command, which properly deserializes PHP objects and arrays, performs the domain replacement, re-serializes correctly, and updates the records. This enabled developers to pull production databases into local environments with proper domain substitution.

Challenge 3: Auxiliary Services

Before migration, audit everything running on the existing server. Standard LAMP stack is straightforward, but hidden services cause surprises.

On Client B's server, I discovered a previous developer had added Redis caching. During peak traffic, every request was making an HTTP call to fetch blog content from another company site. The Redis layer cached these results with a 30-minute TTL—a smart optimization that meant I needed a dedicated Redis server in the new architecture.

Implementation: Infrastructure as Code

Phase 1: Get Code into Git

The existing workflow was FTP uploads directly to production. No version control, no dev environment, no testing. First step: commit everything to Git.

# .gitignore
wp-content/uploads/     # Media library on S3
.env                    # Environment-specific config
*.log

I modified index.php to load a .env file into $_ENV, and updated wp-config.php to read from environment variables:

# .env file per environment
DB_HOST=localhost
DB_NAME=wordpress
DB_USER=wp_user
DB_PASSWORD=secure_password
REDIS_HOST=127.0.0.1
SITE_URL=https://example.com
SITE_HOME=https://example.com

Phase 2: Ansible Playbooks

I wrote Ansible playbooks for each server type—ensuring development and production environments were provisioned identically:

Webserver Playbook: Ubuntu LTS, Nginx/Apache, PHP-FPM with optimized worker configuration, SSL certificates.

Database Server Playbook: MySQL installation, security hardening, backup cron setup.

Redis Server Playbook: Redis installation, memory configuration, connection limits.

Phase 3: Local Development

Using Vagrant + VirtualBox with the same Ansible playbooks:

# Developer workflow
git clone repo
cp .env.example .env
# Configure local .env
vagrant up
# Ansible provisions identical environment to production
php cli db:restore
# Pull and import production database
# Access site at localhost:8080

New developers could be productive within an hour of cloning the repo.

Phase 4: Production Deployment

Production infrastructure on DigitalOcean/AWS:

• 1x Dedicated MySQL server
• 2-4x Webserver instances
• 1x Redis server (Client B only)
• 1x Load balancer

Deployments used Capistrano with built-in rollback:

# Deploy with rollback capability
cap production deploy
cap production deploy:rollback  # If issues arise

Phase 5: Go Live

The cutover process:

1. Staff testing via local hosts file modification
2. Final database sync from legacy server
3. DNS cutover to load balancer IP
4. Monitor for issues

Post-Migration Optimization

With production traffic flowing through load-balanced infrastructure, I focused on server optimization:

Web Server Tuning: Worker processes, connection limits, keep-alive settings, gzip compression, static asset caching headers.

PHP-FPM Configuration: Dynamic vs static process manager, max children based on available memory, request timeouts, memory limits per process.

MySQL Optimization: Query cache, connection pool sizing, buffer pool allocation, slow query logging for ongoing analysis.

Results

Knowledge Transfer

The goal was enabling existing developers to maintain and extend the infrastructure independently. Documentation and training covered:

• README with architecture overview and setup instructions
• Ansible playbook usage for infrastructure changes
• Deployment procedures and rollback processes
• Database backup/restore workflows
• Troubleshooting common issues

If you know how to program, learning to edit a YAML file and run ansible-playbook isn't a big lift. Most developers picked it up within a day.