WordPress scaling questions come in two distinct flavors: many sites, the agency or organization running a fleet, and much traffic, one site absorbing a crowd. They have different answers, and conflating them is how teams end up with the wrong architecture.
Many sites: multisite and its alternatives
Multisite runs a network of sites from one installation: one codebase, one update pass, shared users, per-site content. It shines for structurally similar properties, campus departments, franchise locations, regional editions, and it charges for that in coupling: every site shares plugins, upgrades, and fate, and a database problem is everybody's problem. Sites that need different plugin stacks, separate ownership, or independent lifecycles are better served by separate installs under management tooling that batches updates and backups across the fleet. The governance matters more than the topology: a plugin allowlist, staging-first updates, and a named owner per fleet.
Much traffic: layers, in order
- Full-page caching at the edge or server so most visitors never execute PHP; for anonymous traffic this is nearly the whole answer.
- Object caching with Redis for the queries behind logged-in and dynamic pages.
- A CDN for assets, and offloaded media storage so the web servers stay stateless.
- Then, and only then, bigger or more application servers behind a load balancer.
The database is the last boss
At serious scale the bottleneck is almost always MySQL: slow queries from careless plugins, autoloaded options bloat, and post-meta tables grown monstrous. Query Monitor in staging and a periodic autoload audit prevent most of it. Load-test before the traffic event, not during, and know your numbers: a site that holds at three times expected peak lets everyone watch the launch instead of the dashboards.