Why a sudden traffic spike is different from steady growth
A small website is usually built for the number of people it expects at once, not for every person who might arrive in a few minutes. Each visit asks the site to do work: send page files, look up information, and sometimes run code or query a database. When requests arrive faster than the server can handle them, they wait in a queue. If that queue grows too long, pages slow down, requests time out, or the server stops responding.
The strain can spread beyond the first bottleneck. A page may appear simple, but loading it can trigger several requests—for images, scripts, and data. If those requests all depend on the same overloaded database or network connection, adding more visitors compounds the problem. Some people refresh a stalled page, generating yet more requests just as the site is least able to serve them.
Why adding capacity is not instant
A site can be prepared to handle bursts with tools such as caching, which keeps ready-made copies of frequently requested material, or a content delivery network, which serves files from computers closer to visitors. But these protections take planning, and they may not help with every part of a site: personalized pages or frequently changing information may still need the original server and database.
A sudden spike is also hard to meet simply by adding servers. New capacity may take time to start, and the database or another shared service can remain the limiting step. The result is a mismatch in timing: the crowd arrives all at once, while the site’s ability to expand—or recover—lags behind. That is why a link can make a small site visible to a huge audience and, for a while, make it unreachable to all of them.
