How to approach a system design

"We need a site to sell tickets for our concerts." Most people reach for the whiteboard at once: a database here, a cache there, a load balancer on top. Then the questions start. Which database? How many servers? Does it need a cache at all?

None of those has an answer yet, because nobody has said what the site must do or how big it must be. A design is a set of answers. This page is about asking the questions first, in an order that makes each answer easy:

One example runs through this page: a website that sells concert tickets. Buying a ticket looks like one simple form, but behind it are most of the hard questions in system design: thousands of fans arriving at once, two of them wanting the same seat, and payments that must never be lost.

Functional requirements are the things the system does for its users. Write them as plain sentences that start with "A user can…", and keep the list short. For the ticket site:

• A fan can see which seats are still free, and their prices.
• A fan can choose seats and pay for them.
• A fan receives the tickets by email.

Just as important is what you leave out, and saying so:

Why list what is out? Because every feature you stay quiet about is one somebody assumes is in. A design that tries to cover everything covers nothing well. Three features done properly beat ten sketched.

Non-functional requirements say how well the system must do its job: how fast, how much, how often it may be down. You will also hear them called quality attributes. The features above fit in three lines. These are what make a design easy or hard:

Two rules make these useful:

• Put a number on it. "Fast" is a wish. "The seat map loads in under a second" is a requirement you can design for and test.
• Pick the few that matter. Every system wants all six. Ask which ones would sink this product if missed. Here it is consistency and scale: selling one seat twice, or falling over when the sale opens, is a front-page failure.

To see how much these decide, keep the three features and change only the numbers:

Same features, two very different systems. That is why you ask before you draw. Each quality has its own page later in this track: Latency, Availability & reliability, Consistency models.

You do not need exact figures. You need to know whether you are dealing with tens, thousands or millions, because each calls for a different design. Take the stadium tour:

• Looking. 200,000 fans arrive in the first 10 minutes and each refreshes the seat map about 10 times: 2,000,000 views in 600 seconds, about 3,300 reads a second.
• Buying. 20,000 seats, about two per order, sold out in those same 10 minutes: 10,000 orders ÷ 600 seconds, about 17 orders a second.

That split has already made decisions for you:

• Viewing is huge and forgiving. A seat map that is a few seconds old is fine, so it can be served from memory, copied as widely as needed.
• Buying is small and unforgiving. Only 17 a second, but each one must be exactly right: a seat changes hands once.

Two paths, two designs. Estimation, capacity & cost takes the numbers further: storage, machines and the monthly bill.

The API is the list of things the outside world can ask your system to do. Writing it down turns the requirements into something exact. It is small: roughly one call per functional requirement.

This API is kept deliberately small so the idea is easy to follow. A real ticket site needs more: sign-in, holding seats while a fan pays, a place in the waiting line, and payment that can take more than one step.

Notice the second answer to the order. Writing the API forces the awkward case into the open: two fans press Pay for the same seat, and one of them must be told no.

The data model is what the system must remember in order to answer those calls:

Look at the Seat record: thousands of fans read it, and many try to change it at the same instant. That one record is the heart of the whole design. API first or data model first? Either; they shape each other. What matters is that both exist before the diagram.

Start with the smallest design that meets the functional requirements, and nothing more:

Now hold each non-functional requirement against it and ask where it fails:

• 3,300 seat-map views a second. Every view hits the database, which also has to handle the purchases. Serve the seat map from a cache in memory, refreshed every few seconds.
• 200,000 fans at once. Even with a cache, letting everyone in at the same moment is a stampede. Put them in a waiting line and let them in a few thousand at a time.

Two more are about correctness and staying up:

• Never sell a seat twice. The purchase must check that the seat is free and mark it sold in one indivisible step, in one place that is the single source of truth.
• Never down during a sale. Run several copies of the service behind a load balancer.

This is the habit to keep: start simple, and add a part only when a number demands it. If you cannot name the requirement a box serves, remove the box. Caches, load balancers and queues each get their own pages; the skill here is knowing why each one is in the picture.

Every choice buys something and costs something, and the requirements decide which price is worth paying. One decision shows it: when a buyer picks something, do you hold it while they pay?

Neither is right on its own. Anything sold by the seat holds it: a seat is one of a kind, and losing it at the payment step would enrage thousands of fans in the stadium rush, so ticket sites hold seats, with a short timer. Many online shops don't hold an item in a cart: carts are abandoned all the time, holding stock for them would show items as sold out that are still for sale, and there is usually another one on the shelf. The requirements decided, which is the point of writing them down.

The same pattern repeats in every design:

• Consistency or speed. Checking the one true copy is exact and slower; a copy in memory is fast and a little stale.
• Cost or performance. More machines make the rush smoother, and the bill larger.
• Simple or flexible. A design that handles every future need is harder to build and to run today.

State a trade-off in one sentence with three parts: what you chose, which requirement it serves, and what it costs. "Hold seats for 10 minutes, because fans must not lose them at payment, at the cost of seats locked by people who leave." If you cannot fill in the third part, you have not found the trade-off yet.