The server is on fire.
A food blogger posts about you. Five thousand people arrive at once, and your one server buckles. Everything you built works, there's just far too much of it happening at the same time.
More machines, and a director.
You add more servers and a load balancer to spread traffic across them, with a reverse proxy (often NGINX) as the front door. For this to work, servers must be stateless so any of them can handle any request.
Stop asking the same question.
The database is drowning in identical requests. A cache remembers answers so repeats are instant, and Redis is the fast in-memory store that usually holds it.
Serve from nearby, and don't rely on one database.
A CDN serves images from a server near each user. Replication keeps database copies for more reads and resilience, and sharding splits the data when it outgrows one machine.
Where all this lives.
None of these machines are bought; they're rented from a cloud provider. Containers make each part identical everywhere, and Kubernetes manages them at scale. Under it all sits a choice: one big codebase or many small services.
You worked through Phase 5: it got popular. 16 new concepts joined your architecture along the way.
Next problem: Five engineers now change a live product every day without breaking it.