What is system design? Seeing the whole app behind one tap

On Saturday morning, 100 members of a Kothrud cricket club open SeatJaldi to book ₹299 seats. For a few minutes, nobody can book anything.

Meera Kulkarni put ₹6 lakh of her savings into SeatJaldi, a ticket app for her club in Pune. Everything runs on one ₹1,200-a-month machine, and it had restarted for an update right as members opened the app.

“I will rewrite the booking code to make it faster,” says Arjun Nair, her first hire. Meera asks, “Will faster code stop the machine restarting?” Arjun has no answer. Later he admits, “I do not even know what happens after I tap Book.” All companies, people and numbers in this course are made up.

System design is deciding which parts an app needs, how they talk, and what happens when more people arrive or something breaks. Meera’s question was about the parts, not the code.

Every design is a set of trade-offs. Picture a see-saw with five arms, one for each thing in the list below. Push one arm down and at least one other goes up.

• Speed: answers come fast, but you pay for more machines.
• Cost: the bill stays small, but there is less room for crowds.
• Correctness: every booking is right, but the checks take time.
• Staying up: the app keeps working when a part stops, but a second machine ready to take over costs money.
• Simplicity: there are few parts, but there is one place to break.

You have seen this when a shopping app is quick on a quiet afternoon but spins during a big sale. Same parts, bigger crowd, and the first part to run out makes everyone wait.

You have seen an app say “Down for maintenance” while the same company’s website works. Often one part had nothing ready to take over while it was updated. A second machine would have cost more, so the company chose cheap over always on. That was a trade-off, not a bug.

A simple app needs three parts: a phone app that asks, a server that runs the code, and a place that remembers. That place is the database. Like Sunita’s one kitchen and one gas cylinder, each part is cheap and can run out.

SeatJaldi’s server checks which seats are free and takes each booking. Its database keeps every seat and booking, on the same machine.

The one machine runs out of room to work first. It can handle only so many bookings at once, so the rest wait in line. The ones that wait too long fail with an error. And if the machine stops, everything stops, like on Saturday.

In SeatJaldi v0, the whole machine is the single point of failure. Like Sunita with one gas cylinder, Meera has nothing to switch to.

HLD, high level design, is the boxes, arrows and trade-offs of the whole app, like the SeatJaldi v0 drawing. LLD is how the code inside one of those boxes is organised.

At Sunita’s wedding, HLD is three kitchens, two counters and a store room. LLD is how one cook arranges one kitchen’s shelves. Both matter, but they get decided in different meetings.

In a design review, a meeting where the team checks a plan before building it, engineers work through the four steps below. When the numbers change, they go round again. Sunita asks the same two things: what is the plan, and what if the gas runs out?

1. 1

   Write what it must do

   Members pick a seat, pay ₹299 and get a ticket.

2. 2

   Put numbers on it

   For SeatJaldi today: 100 members, ₹1,200 a month, and how many book in the busiest minute. Nobody has measured that last one yet.

3. 3

   Draw the boxes

   Only the parts the first two steps need. That is still v0.

4. 4

   Review what fails

   Ask every box the three questions below.

Adding parts is never free either. Parts on different machines talk over the network, the wires between computers. That is slower than inside one machine, and more can break on the way.

So write down the reason, not only the diagram. One machine: 100 members fit, and it costs ₹1,200.

Try it yourself

1. 1

   Pick an app

   Choose one you use daily, such as a food or train app.

2. 2

   Write three to five parts

   Such as the phone app, accounts, orders, a payment partner.

3. 3

   Draw the arrows

   One arrow from each part to the part it talks to.

4. 4

   Circle one part

   Circle the part that would hurt most if it stopped, and guess whether the real app has a second one ready. Write: “It gains X, but the price is Y.”

5. 5

   Check your work

   You have 3 to 5 boxes, each with an arrow, and a yes or no beside the circled box for “has a second one ready?”. A no is why it would hurt most. Your sentence names a gain and a price. If it names only a gain, you wrote a wish, not a trade-off.

Back in Kothrud, Arjun draws SeatJaldi v0 for Meera. Meera is Sunita with 100 guests, and one kitchen is right for today. One machine keeps the bill at ₹1,200 and gives them one thing to understand. The price is a single point of failure.

Now Meera’s question has its design answer. Faster code would not stop the restart, because every update needs one. A second machine that can take over, with its own copy of the seats, would keep booking open, but it costs more rupees. A cheaper fix for planned updates is to run them late at night, when almost nobody books. That does nothing for a crash, though. Only numbers will say when to pay for more.

They keep one machine for now, and Arjun promises to ask the gas question every time: what if this part stops? But one question still bugs him. When Arjun taps Book, what actually happens between his phone and that server?