Picture a ticket-booking site that works perfectly for 10 testers. Then sale day arrives, 50,000 people click "Book" at 10 AM, and everything freezes. Nothing was wrong with the code. What was missing was a design: someone deciding in advance how the system should behave under pressure. That skill is System Design, and it comes down to making smart trade-offs.

Plan the wedding before you cook the menu

Think of organising a big wedding. First you decide the venue, the caterer, how guests flow from parking to the stage, and what happens if it rains. That is High-Level Design (HLD): the big picture and the structure.

Only then do you sort out the details: the exact menu, how much salt goes in each dish, who sits at which table. That is Low-Level Design (LLD). A great cook who has never planned the event is still just a cook. The planner is the architect.

HLD vs LLD: the planner and the cook

Ask "What?" before you draw

Suppose someone says, "Design a food delivery app." Resist the urge to draw boxes. Define the requirements first.

  • Functional (the What): Can I browse restaurants? Place an order? Track my rider?
  • Non-functional (the How): Does the order confirm within 2 seconds? If the payment fails, is my order lost or safely retried? Does the app survive the Friday 9 PM dinner rush?

The second list is what separates a weekend project from a product people trust.

The 9 tuning knobs

Every system is shaped by nine qualities: scalability, availability, reliability, performance, consistency, durability, security, cost and maintainability. Think of a phone camera. More megapixels means bigger files and slower sharing. Better night mode means a higher price. You cannot max out every knob at once.

The system qualities and the trade-offs between them

There is no "best" answer

When you buy a phone, you pick between great battery, slim design and a low price, and you will not get all three. Software forces the same choice.

Take railway seat booking. Two people tap the last seat at the same moment, and exactly one must get it. That needs strict consistency, even if it makes the page a little slower. Now take the "12 people are looking at this" banner on a shopping site. If it shows 12 when the real number is 14, nobody is harmed, so the site picks speed and availability and lets the number catch up a moment later.

Consistency first for seat booking, speed first for the viewer count

The takeaway

An architect does not hunt for the right answer. They hunt for the least bad trade-off for the problem in front of them, and they can explain why.

Next in this series: what really happens behind the scenes between your tap and the screen filling up.