What is system design?
System design is deciding which parts a piece of software needs, such as servers, databases, caches and queues, and how they work together so it stays fast and reliable as more and more people use it.
See one in 11 seconds
Below is a small, real-world design. Press Play to watch a request go out through it and come back, one hop at a time. Select any box to see what it does.
Open the full URL Shortener page, with more flows and a plain-text version.
Why it matters
A small app can run on one computer. When thousands of people use it at once, one computer isn't enough: it runs out of memory or processing power, and when it goes down, everything goes down with it. System design is how you spread the work across many machines without losing data or making people wait.
It's mostly about trade-offs. A cache makes reads faster but can return data that's slightly out of date. A queue absorbs sudden bursts of traffic but adds a delay. Keeping several copies of a database survives a broken machine, but the copies have to agree with each other. There's rarely one right answer, only choices that suit the problem.
The building blocks
Most designs are made from the same few kinds of parts. Every diagram on HowItScales uses these, each with its own colour.
| Part | What it does | For example |
|---|---|---|
| Client | What people use to reach the system. | A browser, a phone app |
| Gateway | Where requests enter, before they reach the services. | A load balancer, an API gateway, a CDN |
| Service | Does one job for the system. | Sign-in, payments, search |
| Queue | Holds work or events until something is ready for them. | Kafka, RabbitMQ, Amazon SQS |
| Database | Keeps data for the long term. | PostgreSQL, MySQL, DynamoDB |
| Cache | Keeps copies of data in fast memory, for quick answers. | Redis, Memcached |
| External | Run by someone else, outside this system. | A payment provider, a maps service, DNS |
Arrows connect the parts and show who talks to whom. A flow is one request following those arrows, there and back.
The questions behind every design
Designing a system starts with questions, not boxes:
- How much traffic? How many requests per second on a normal day, and at the busiest moment?
- How much data? How much is stored today, and how fast does it grow?
- How fast? How long can someone wait for an answer before they give up?
- What must never be lost? A payment matters more than a like.
- What happens when something breaks? Machines fail every day at scale. Which parts can go down without anyone noticing?
The answers decide the parts. Lots of reads of the same data suggest a cache. Sudden bursts suggest a queue and more copies of a service. Systems with a Simulation badge let you push the traffic up and watch what gives way first.
Where to start
Work through these in order. Each one adds ideas on top of the one before.
- Loading a Web PageBeginnerWhat happens when you type a URL into your browser: DNS finds the server, TCP and TLS connect securely, a CDN serves the page.
- URL ShortenerBeginnerTurns long links into short ones and redirects fast, with a cache in front of the database.
- SwiggyIntermediateHow a food delivery app works: which restaurants can reach you, predicting prep and delivery time, and assigning delivery partners.
- UberAdvancedLive driver locations, matching through a geospatial index, and surge pricing.
System design in interviews
Many companies ask experienced developers a system design question, such as “design a chat app” or “design a news feed”. There's no single right answer. Interviewers listen for how you:
- ask what the system must do, and for how many people;
- estimate the traffic and the data;
- sketch the main parts and the arrows between them;
- follow one request through the design, out and back;
- find what breaks first under load, and explain the trade-offs of fixing it.
Playing a flow here, then explaining each step out loud, is good practice for the last two.
Common questions
Is system design only for senior engineers?
No. Anyone who builds software benefits from knowing where a request goes and why. Senior roles are simply expected to make these decisions themselves.
Do I need to code to learn it?
Not to start. It helps to know what a server and a database are. The diagrams here need no code at all.
What's the difference between high-level and low-level design?
High-level design is the parts and how they connect, which is what this site shows. Low-level design is the inside of one part: its classes, functions and data structures.
Are the diagrams how real companies work?
Simplified versions. Every part says whether it's documented with a public source, an assumption, or hypothetical, so you always know how sure we are.