Scalability 101: More Users, More Problems
Let’s imagine running into a good problem. I deployed my app. The website is getting more and more traffic everyday. It’s popular. How could I architect it so that it can handle more users? (Because no one wants to use a website if it is too slow. Performance issues.)
Vertical scaling would be the most straightforward approach after refactoring code and taking Big O into account. Get more resources to handle it. Get more RAM, CPU, and Disk space. Eventually, that approach hits a limit. The latest and greatest machine won’t be enough. Money is exhausted. So let’s think of another approach.
Horizontal scaling means adding more machines. Let’s go from 1 web server to 2… or 200, not necessarily the most state-of-the-art machines but having more will improve performance.
If I do introduce horizontal scaling, I need to readjust my thought process on client-server model. (My world felt simpler with one client and one server with one IP address.) The client-server model describes how data is exchange through a request/response cycle. I type a URL into my web browser. The browser sends a request to DNS server to get the IP address and then get a response from the server. What happens when there is a bunch of servers? (assuming
Let’s throw in DNS load balancing.
A client reaches out to a load balancer and then will get one of the servers. The client could get one assigned randomly by the load balancer. Ideally, it would get one that is least busy.

Solution Summary
With heavy user traffic, a developer can go through three general approaches to improve performance.
- Refactoring code for performance
- Vertical scaling
- Horizontal scaling

Now, people can use the web app with ease.
