It’s easy to think that serving a large audience requires a server room the size of a warehouse. However, this is not always the case. If your site is static, a small machine can handle hundreds of thousands of visitors. Imagine a simple 500MHz Celeron running Linux and Apache. Connect to a T3 line (45 million bits per second). This setting handles very large amounts of traffic. ISPs rent the entire setup for less than $1,000 a month.
But here’s the problem. The most popular sites are not small. They quickly hit the wall. One box cannot be expanded indefinitely.
“If you have to deal with millions of visitors and dynamic content, your machine will break.”
Limits appear when a certain threshold is reached. First, you may have to support millions of visitors every day. A single CPU has limitations. The second is a hardware failure. If one of your servers goes down, your site will go dark until you replace it with a new one and configure it again. Third, large or complex pages consume resources quickly. Fourth, if the page has to change dynamically for each user, the server has to work harder. Finally, background processing adds latency. Most large sites meet all these criteria and therefore require extensive infrastructure.
The three most important scaling strategies
If the budget allows, engineers can choose three main routes during peak traffic.
- Buy a huge machine with unlimited power and redundancy.
- Divide the load among many smaller machines.
- Combine the two methods.
The distributed approach is most common in large web applications. You may have even seen this in action without realizing it. If the URL changes slightly every time you visit and refresh the website (for example www1.xyz.com and www2.xyz.com ), that’s a clue. This site uses a series of independent computers. Everyone uses web server software. They all use the same website page copy.
The real magic is in how incoming requests are distributed. This can happen in two main ways.
DNS-based load balancing
The Domain Name System (DNS) translates human-readable names into IP addresses. Some DNS configurations use a round-robin approach. DNS servers cycle through the list of available IP addresses each time a request is received.
This naturally distributes the load. Each server receives a portion of the traffic. They don’t talk to each other about the load. Only provide static or pre-generated content they have access to.
Load balancing switch
A more advanced approach involves a load balancer. All network traffic first reaches the central switch. This machine acts as a traffic policeman. Forwards the request to an available server.
The switch does not just guess. Check each server to see which one is the least busy. This guarantees an even division of work. HowStuffWorks has taken this approach. The company’s load balancer distributes the traffic between three different web servers. If one of them fails, the other two will keep the site live. No downtime for the user.
This redundant configuration has clear advantages. The failure of one machine does not crash the whole site. You can also increase the capacity in stages. Need more power? Add another box. It is flexible.
There is one downside. These distributed machines still often rely on centralized databases for transaction processing. As traffic grows, this database became a bottleneck.
One huge machine
Not everyone distributes. Microsoft’s TerraServer takes the “single large machine” route.
TerraServer stores terabytes of satellite images. It handles millions of requests for that data. it uses huge enterprise-class hardware. Take the Digital AlphaServer 8400 for example. It has eight 440 MHz 64-bit processors. Contains 10 GB of error-checked and corrected RAM.
That is a lot of power in one chassis. This avoids the complexity of network coordination between multiple servers. But it is expensive. If one AlphaServer fails, the service stops.
The choice depends on your business model. Static content favors simple setups. Dynamic transactions demand redundancy. Data-intensive applications may require raw power.
If you want to learn more, there are plenty of resources. The W3C sets the standards. Microsoft has published a white paper on Windows NT load balancing. IBM provides a red book on server balancing. A paper on distributed collaborative web servers describes this theory.
But the core reality remains simple. Traffic scales. Hardware limits. Engineers build a bridge between the two. How you build it depends on what your website will actually be used for.
