Module 3 · Serving More People, Faster · Lesson 8 of 35
Vertical vs horizontal scaling: a bigger machine or more machines
11 minFree System design course · Beginner to intermediateLesson 3.1By Saket Bhatnagar
Researched and drafted with AI, reviewed and edited by Saket Bhatnagar.
In short
- Vertical vs horizontal scaling is the choice between one bigger machine and more machines of the same size. A bigger machine is simple but has a ceiling. More machines grow further.
- A bigger machine is still one machine. When it restarts or breaks, nobody can use the app.
- More machines help only if any of them can serve any user, so what they remember must live in one shared place.
Video lesson · coming soon
Vertical vs horizontal scaling: bigger or more?
Lala, your AI mentor, will walk you through this lesson in a short animated video. Until then, everything is here to read and try.
- 01 The ₹9,000 off switch
- 02 A bigger tawa or three cooks
- 03 Both roads end at one database
- 04 Flip the four cards
- 05 Logged in on one, not on four
- 06 Sketch your app both ways
SeatJaldi’s most expensive machine is also its off switch. Meera Kulkarni, unsure at first, had let Arjun try his idea. She moved the app from the ₹1,200 server to a 16-core one at ₹9,000 a month, 7.5 times the price. A core is one part of the chip that does the work, and the club-league sale ran fine.
Then one night Arjun Nair restarts that big server for a security patch, a fix for a safety hole. Until it comes back, SeatJaldi does not exist for anyone. Arjun lays out two ways to grow from here: an even bigger machine, or several of the first one’s size.
“What does each cost in rupees?” Meera asks. “And what do I tell users when one dies?” They pick four app servers of that size. The database moves to its own machine, the 16-core one, and every app server talks to it over the network.
Arjun sets them up on the test site, a practice copy that real users never see. He logs in, taps once, and is asked to log in again. Meera wants a line she can repeat: why more machines, not a bigger one? And why does Arjun’s login look fine on one server and strange on four?
What is the difference between vertical vs horizontal scaling?
Vertical scaling means buying a bigger machine, as SeatJaldi did with the 16-core server.
Horizontal scaling means adding more machines of the same size and sharing the work. That is the four-server plan.
- A bigger machine is simple, but it has a ceiling and it is one machine.
- More machines can keep growing, and the app survives one of them dying.
- More machines need one shared place for whatever they remember.
One big box or four small boxes
Drag to explorePhones reach either one big server or four small servers, and with four, something must spread the taps between them. Both options end at the same single database, which limits how far horizontal scaling can go.
Diagram connections:
- Phones to One big server (Requests (vertical))
- Phones to Four small servers (Requests (horizontal))
- One big server to One database (Reads, writes)
- Four small servers to One database (Reads, writes)
- Phones: Users tapping Book on the app.
- One big server: Vertical scaling: one machine made bigger to do all the wor…
- Four small servers: Horizontal scaling: four copies of the app, ₹1,200 each.
- One database: Holds the data; with four servers, it moves to its own 16-c…
You have seen an exam-result site that is fine all day, then shows everyone the same error page when results open. Behind the screen, one machine was full, and only a bigger one or more of them could help.
A food-delivery app is quick at 3 pm, crawls at 8 pm and is fine again by 11 pm. Load comes and goes, so renting more machines only for busy hours makes sense.
Why does a bigger machine stop being enough?
Because there is a biggest machine you can buy, every step up costs more, and while it restarts or breaks nobody can book. Vaishali’s tawa cannot outgrow her counter.
What breaks when you add more machines?
Anything one server remembered for itself breaks, because the next request may land on a different server. Arjun logs in on one server. His next tap reaches another server, which has never met him.
On one server, keeping state in its own memory is harmless, because the next tap has nowhere else to go. With three cooks, it is like each cook keeping orders in their own head.
| What the server remembers | Works on one server | Breaks on four |
|---|---|---|
| Who is logged in | Every tap reaches the server that saw the login. | The next tap may reach a server that never saw it. |
| Two ₹299 seats in a cart | The cart is always there. | The cart looks empty on the other three. |
| Seats sold, counted in the server’s memory | One count, always right. | Four separate counts, each too small, so seats can be oversold. |
What just happened? Each server was fine alone, but four memories disagreed. Where that memory should live is the next lesson’s job. In one line: a bigger box has a ceiling; more boxes need shared state.
How do engineers choose, with numbers?
Engineers start vertical, measure, and go horizontal when the numbers or the risk demand it. Vaishali buys the bigger tawa first, and hires cooks when she hits the counter.
First, the raw need. The noon peak is about 16,700 requests a second, and one ₹1,200 server handles about 200: 16,700 / 200 = 83.5, about 84 servers. At ₹1,200 each, 84 x 1,200 = ₹1,00,800, plus the ₹9,000 database machine: about ₹1.1 lakh a month.
Most of those requests ask for the same seat map, so the next lessons cut the load with copies of answers, not endless servers.
Second, the shared limit. Suppose, as an assumption, the database machine answers 2,000 queries a second, a query being one question to the database. If each request asks 2 queries, 2,000 / 2 = 1,000 requests a second. That is 1,000 / 200 = 5 servers’ worth, so the 84-server plan would stop at the database long before the 84th server.
Third, the failure share. With four servers, losing one leaves 3 x 200 = 600 of 800 requests a second, which is 75%. What just happened? Three numbers decided it: one big machine leaves 0% when it stops, the 84-server plan costs about ₹1.1 lakh, and the database stops at 5.
- A bigger machine helps only if the app can use it. A program that does its work on one core gets little from 16.
- Rules can add servers as load rises and remove them after, called autoscaling. New servers take time to start, so start them before noon.
- Teams often keep growing the database vertically, because every copy of the data must agree.
Try it yourself
Write today’s numbers
One ₹1,200 server handles about 200 requests a second. Four times the load is 4 x 200 = 800 a second.
Price it horizontally
800 / 200 = 4 servers. Assuming each costs the same as the first, 4 x ₹1,200 = ₹4,800 a month. Add the ₹9,000 database machine: ₹13,800 in all.
Price it vertically
Assume, and say so, that the ₹9,000 server can carry all 800 a second, database included. Write down ₹9,000 a month.
Lose one machine
Work out what each plan still serves if one machine running the app dies. Name one cost the rupees do not show.
Check your work
You got it right if you have 4 servers, ₹4,800 (₹13,800 in all), ₹9,000, and 600 a second left against 0. 600 is short of 800, so a careful team adds a fifth. The hidden cost is shared state and something to spread requests.
Back at the SeatJaldi office in Kothrud, Meera asks it the way Vaishali would: “Bigger tawa or more cooks?” Arjun’s answer is both, in order. The bigger machine was right for the league, while load was modest and a short restart at night was acceptable.
For the final, they go wider: there is a biggest machine, one machine is a single point of failure, and load comes and goes. In rupees, four ₹1,200 app servers plus the ₹9,000 database machine cost ₹13,800 a month, more than the one ₹9,000 box. The extra ₹4,800 buys survival. Once any server can serve any user, Meera can tell users the app stays up if one app server dies, with 75% left.
The honest part: four servers carry about 800 requests a second, not 16,700, and the database stays a single point of failure until later lessons. More boxes also need shared state, and Arjun’s test showed it is not there yet. With four servers, Arjun’s users are logged out at random. Why, and where should the memory live?
Check yourself
Check yourself
SeatJaldi goes from one server to four identical servers, and users report random logouts. What is the best explanation?
Pick an answer to see why it is right or wrong.
Check yourself
What is the strongest reason to go horizontal for the Monsoon T20 Cup final?
Pick an answer to see why it is right or wrong.
Check yourself
A teammate says, “We have four servers, so the app is now four times faster, at any load.” What is the best reply?
Pick an answer to see why it is right or wrong.
Remember these three
- A bigger box has a ceiling; more boxes need shared state.
- Go bigger first while load is modest. Go wider past the biggest machine, or when one failure would stop the app.
- More servers help only until a shared part, usually the database, is full, and only if no server keeps a user’s details to itself.
Questions people ask
- What is the difference between vertical and horizontal scaling?
- Vertical scaling makes one machine bigger; horizontal scaling adds more machines of the same size and shares the work. Vertical is simpler, while horizontal grows further and can survive one server dying.
- What is scale up vs scale out?
- Scale up is another name for vertical scaling, and scale out is another name for horizontal scaling. Scaling up gives one machine more cores or memory; scaling out adds machines beside it.
- Which is better, vertical or horizontal scaling?
- Neither always wins. Vertical is simpler while load is modest and a short restart is acceptable. Horizontal is needed past the biggest machine, or when one failure would stop the app.