How to Approach a System Design Problem, Step by Step

The bike-share nobody rode on a Tuesday#

This is part 2 of the System Design Introduction, and it stands on its own. A system design problem arrives deliberately vague: "design a bike-share", "design a chat app". There is no spec. Working out what to build is part of the job, and a repeatable approach is what stops you building the wrong thing well.

Picture a mid-sized town. The council says: "We want a bike-share scheme." A rival team pitches first. They hear "bikes", notice the old castle is busy with tourists at weekends, and put most of the docks there. On Saturday it looks great. On Tuesday at 8 am the bikes sit by the castle while hundreds of people walk to the train station. The council meant weekday commuters all along. Nobody asked.

The rival team's docks worked and their app worked. They answered a question nobody had asked. Tomás, a planner at the council, gets the same request, the same town and the same money. Instead of placing docks, he walks five steps.

The five steps, and what each one produces#

Each step produces something you can point at. That is how you know a step is finished.

1. Clarify requirements → a short list: who uses it, what it must do, how well, and what is out of scope.
2. Estimate the size → a few rough numbers for users, peak use and storage. Enough to tell small from huge.
3. High-level design → a box diagram of the whole system, end to end, with no detail yet.
4. Deep dive → one part, the hardest or busiest, designed properly, with its bottleneck found.
5. Trade-offs and wrap-up → what you chose, what it costs, and what you would change at 10x.

The order matters. Requirements tell you what to count. The numbers tell you how big the boxes must be. The boxes show you where to dig. This is adapted from the System Design Primer, a widely used open guide, which follows the same arc: use cases and constraints, a high-level design, the core components, then scale.

Steps 1 and 2: ask, then count#

Tomás draws nothing on day one. He asks questions and sorts the answers into three piles.

• Functional requirements, what it must do: a rider unlocks a bike with the app, rides, and returns it to any dock. The app shows which stations have bikes.
• Non-functional requirements, how well it must do it: at 8 am there is a bike within five minutes' walk of where commuters live, it works in the rain, and unlocking takes seconds, not a minute.
• Out of scope: e-bikes in phase one. Writing this down matters as much as the rest. It is what you promise not to build.

The most important answer is to "who uses it?": weekday commuters heading to the train station and the Riverside offices. That one answer, the one the castle plan never got, moves every dock in the scheme.

Next he counts, roughly. In this example:

The verdict: for the computers, this is small. One modest server and one database can handle a ride every 11 seconds with room to spare, and even a year at 1,600 rides a day, about 584,000 ride records, fits easily in one database. So the hard part of this system is not the software. It is where the bikes are. Estimation gets its own lesson next. Here you only need enough to know whether you are building a shed or a stadium.

Steps 3 and 4: draw the boxes, then find the bottleneck#

Step 3 is a map of the whole system, end to end, before any detail:

A rider taps unlock. The central system checks their account and tells the dock to release the bike. When the bike goes back into any dock, the dock reports it, the ride ends and the payments box charges the fare. Every requirement from step 1 has a home, and nothing is designed in depth yet.

Step 4 picks the hardest or busiest part. Step 2 already said the servers are easy, so Tomás looks at the 8 am rush. Here is one weekday hour at four of his stations, in this example:

For each station, work out bikes at 8:00, plus returned, minus taken:

• Train station: 25 + 10 − 70 = −35. A station can't hold fewer than zero bikes, so it runs dry. If rides are spread evenly through the hour, it is empty by about 8:25, and 35 commuters find no bike.
• Riverside offices: 10 + 55 − 5 = 60 bikes for 30 docks. It is full by about 8:24, and 30 riders can't return their bike at the end of the ride, on their way into work.
• Market square: 12 + 8 − 10 = 10. Fine.
• University: 15 + 15 − 20 = 10. Fine.

Step 5 and the expert corner#

Tomás has three ways to fix the imbalance, and each one has a cost:

• A rebalancing van moves bikes from Riverside back to the train station before and during the rush. Reliable, but a running cost every weekday: a van and a driver.
• More docks at Riverside fix the overflow, but cost money and pavement space, and do nothing for the empty train station.
• A discount for returning bikes to the train station is cheap, but unreliable. On a rainy morning, few people will ride back the other way for a small discount.

His wrap-up says it plainly: "For phase one I chose the van plus the discount. The van is reliable and the discount trims how many bikes it has to move. It costs a driver every weekday. At 10x, 16,000 rides a day, one van can't keep up, so I'd add docks near the offices and more vans, and start measuring the servers: nearly a ride a second is still modest, but now worth watching." That is step 5: a choice, its price, and what changes at scale.

Where it breaks. The approach fails in two predictable ways. Skip step 1 and you get the castle docks: a solid design for the wrong problem. Jump to step 4 too early and you spend an hour perfecting the dock's lock before you know where the docks go. A quieter failure is false precision in step 2. You want the order of magnitude, not three decimal places.

In a system design interview. The same five steps work for "design a URL shortener" or "design a photo-sharing app": ask who uses it and what it must do, estimate, draw the boxes, go deep where the numbers say it hurts or where the interviewer pushes, then name your trade-offs. One common way to split a 45-minute interview, as a rough guide rather than a rule:

• The first 5 to 10 minutes: requirements and estimates.
• About a third: the high-level design.
• About a third: the deep dive.
• The last few minutes: trade-offs and what changes at 10x.

Recap: ask before you draw#

Tomás and the rival team had the same town and the same budget. The difference was the order of the work: questions before docks, numbers before servers, one deep dive where it hurt, and an honest list of what each fix costs.

Ask before you draw: requirements, numbers, boxes, one deep dive, then the trade-offs.

Next in the series: back-of-the-envelope estimation, the quick maths behind step 2.

Practice

Check your understanding

FAQ

Frequently asked questions