Software architecture
System design
System design is the process of choosing a software system's components, data stores and interactions so it meets its functional and scale requirements.
Teams do system design before writing code because the expensive decisions, how data is stored, how components talk and where the system breaks under load, are cheap to change on a whiteboard and costly to change in production. It is also a standard interview format, because it shows how an engineer reasons about scale.
Why does system design matter?
- It surfaces requirements early. Writing down what the system must do, how fast and for how many users exposes gaps before they become rework.
- It makes scale a design input. A system for 100 users and one for 100 million share a feature list and little else.
- It records trade-offs. Every design gives something up. Writing the choice down as an architecture decision record keeps the team from relitigating it and makes deliberate technical debt visible.
- It gives reviewers something to review. A design review needs a document and a diagram. System design produces both.
What are the parts of system design?
A system design has four parts, and they are done roughly in order.
- Functional requirements. What the system does: shorten a URL, redirect a visitor, expire a link after a year.
- Non-functional requirements. How well it must do it: redirects in under 50 ms, 99.99% availability, links that never collide. These decide the architecture.
- Scale estimates. Back-of-the-envelope numbers for traffic, storage and bandwidth. The point is to know whether the database fits on one machine.
- Trade-offs. The reasons behind each choice and what it costs: consistency or availability, a managed service or self-hosting, one region or several.
What are the common building blocks?
Most systems are assembled from a small set of components. Knowing what each one buys you, and what it costs, is the core skill.
| Building block | Use it when | What it costs |
|---|---|---|
| Load balancer | Traffic exceeds one server, or you need failover | A new single point to make redundant |
| Cache | Reads far outnumber writes and stale data is acceptable | Invalidation logic and an extra hop on a miss |
| Relational database | Data has relationships and needs transactions | Harder to scale writes horizontally |
| NoSQL store | Simple access patterns at very high scale | Weaker consistency and no joins |
| Message queue | Work can happen later, or producers and consumers run at different speeds | Eventual consistency and a queue to monitor |
| CDN | Static assets served to users around the world | Cache invalidation and cost per request |
Named architecture patterns such as microservices or event-driven architecture combine these blocks in standard ways.
How does system design work?
The diagram at the top of this page shows the process and the design it produced for a URL shortener. Requirements came first: create a short link, redirect quickly, keep links for ten years. Then estimates. At 100 million new URLs a day the write rate is about 1,200 per second, reads are roughly ten times that and ten years of links is about 365 billion rows, more than fits comfortably in one database.
Those numbers shaped the high-level design. Reads dominate, so a cache in front of the database serves the most popular links without touching it. Writes must never collide, so a separate ID generator hands out unique codes in advance instead of checking the database on each insert. The deep dives then covered the hot spots: cache eviction, how the ID generator survives a restart and how the database is partitioned.
The last step names the trade-offs. Caching means a link can be a few seconds stale after an update. Pre-generated IDs mean a small range of codes is wasted if a server dies. Both were written down.
How do you do a system design?
- Clarify the requirements. List the features, then the non-functional targets. Ask about the edges: what if a link is deleted, or two users submit the same URL.
- Estimate the scale. Work out requests per second, storage per year and bandwidth.
- Draw the high-level design. Put the user on the left and let the request flow right through the main components. Keep it to ten boxes or fewer, then name the main entities and the APIs that read and write them.
- Deep dive on the risks. Pick the two or three places the estimates say will hurt, usually the data store and the hottest path, and design them in detail.
- Write down the trade-offs. For each major choice, note the alternative and why it lost.
- Review it. Put the document and the architecture diagram in front of the people who will run and extend the system.
What are common system design mistakes?
- Designing for scale you do not have. Sharding on day one adds complexity a single database would have avoided for years.
- Skipping the estimates. Without numbers, every component is a guess and every argument is about opinions.
- Ignoring failure. A design that only shows the happy path is not finished. Ask what happens when each box disappears.
- Treating the diagram as the design. The boxes matter less than the reasons behind them. Keep the trade-offs with the picture.
How does system design compare with other terms?
System design is the activity and system architecture is its main output. Applied across several applications to solve one business problem, the same activity is called solution architecture. Architecture patterns are the named structures a design draws on, and the C4 model is a good format for drawing the high-level design and the deep dives at consistent levels of detail.
What about system design interviews?
The interview version compresses the same process into 45 minutes. The prompt is something like “design a URL shortener”, and the interviewer expects the candidate to clarify requirements, estimate scale, draw a high-level design, deep dive where asked and explain the trade-offs. Candidates who say why they chose each component do well. Candidates who draw a memorized diagram do not, because the follow-up questions are about the reasons.
What tools help with system design?
- Whiteboards and documents. Most designs start as a sketch and a one-page document with the sections above.
- Diagram-as-code tools. Writing the diagram as text keeps it in the repository with the design document, so the two are reviewed together. See diagram as code.
- AI diagramming tools. Tools like Eraser turn a written design into a system architecture diagram you can keep editing, the fastest way to get a picture reviewers can argue with.
For more on this kind of diagram, see design docs.
Frequently asked questions
-
What is the difference between system design and system architecture?
System design is the activity: gathering requirements, estimating load, choosing components and weighing trade-offs. System architecture is the result, the structure the activity produces. The terms overlap in practice, and a system design document almost always contains an architecture diagram of the result.
-
What is the difference between high-level design and low-level design?
High-level design names the major components, such as services, databases, caches and queues, and shows how they talk to each other. Low-level design works inside one component: its data model, APIs, classes and algorithms. A system design covers the high level fully and goes low only where the risk is.
-
What are non-functional requirements in system design?
Non-functional requirements describe how well the system must work rather than what it does: latency, throughput, availability, durability, consistency, security and cost. They decide most of the architecture. Two systems with the same features but different availability targets can end up with completely different designs.
-
How do you prepare for a system design interview?
Practice the process rather than memorizing answers. Clarify requirements, estimate scale, draw a high-level design, then deep dive where the interviewer points. Know the common building blocks and their trade-offs, and be ready to explain why you chose one option over another.
