What Is System Design in Software Engineering?
System design is the process of deciding which parts a software system is made of, how those parts communicate, and how data flows through them, so that the system meets its requirements for scale, reliability, and cost. The output is a design: a set of named parts, the connections between them, the data model, and the reasoning behind each choice. The work happens before the code is written and again whenever the requirements change.
The term is broader than software architecture and narrower than software engineering, and the sections below draw both lines. Readers who searched for the four commonly listed types of system design will find that list in What are the 4 types of system design?.
What a System Design Covers
Requirements
A design starts with functional requirements, which say what the system does, and non-functional requirements, which say how well it must do it. "Users can shorten a URL" is functional. "The redirect must answer within 100 ms for 99 percent of requests" is non-functional. Every later decision is checked against these two lists.
The Main Parts
Most systems are built from five part types. Clients send requests, services hold the logic, databases store records, caches keep frequently read data in memory, and queues pass work between services without making the sender wait. The design names which of these exist, how many of each, and what each one is responsible for.
Data Model and Storage
The data model lists the entities, their fields, and the relationships between them. The storage choice follows from the access pattern: a relational database when records are related and need transactions, a key-value store when every read is a lookup by id, and an object store for large files. The design also states which copy of the data is the source of truth.
How the System Scales
Scaling means handling more users, more data, or more requests without a redesign. The usual tools are horizontal scaling, which adds machines behind a load balancer; sharding, which splits a database by key so each machine holds part of the data; and caching, which answers repeated reads without touching the database. The design says which of these are applied and at what load.
How the System Fails and Recovers
Every part will fail at some time, so the design states what happens when it does. Replication keeps a second copy of the data so a dead database does not lose records. Failover moves traffic to a healthy machine, and retries with timeouts stop one slow service from stalling every caller. The design gives numbers here: 99.9 percent availability is about 8.8 hours of downtime a year, and 99.99 percent is about 53 minutes.
High-Level Design vs Low-Level Design
High-level design (HLD) is the view of the whole system: the services, the databases, and the connections between them. Low-level design (LLD) is the inside of one service: its classes, interfaces, and the algorithms it runs. A system design interview mostly asks for the high-level view, while an object-oriented design interview asks for the low-level view. The two are compared in LLD vs. HLD.
A Worked Example: A URL Shortener
Requirements. Users submit a long URL and receive a short one, and visiting the short one redirects to the long one. Reads outnumber writes by about 100 to 1, a redirect must finish in under 100 ms, and the service must store 30 billion links.
Parts. A web client, an API service that creates links, a redirect service that resolves them, a database, and a cache in front of the database.
Data model. One table with a seven-character key, the long URL, the owner id, and a creation time. A key-value store fits because every read is a lookup by key.
Scaling. The redirect service keeps no state, so more copies run behind a load balancer. The cache holds the most-visited keys, and the database is sharded by key when one machine is not enough.
Failure. The database is replicated, the cache may be lost and rebuilt, and a redirect that misses the cache reads the database with a timeout.
That is a complete first design. A longer version of the same walk-through is in What is system design with an example?.
System Design vs Coding
Coding produces working functions inside one program, while system design produces the plan for many programs and the machines they run on. A coding task asks whether an algorithm is correct and how fast it runs. A design task asks where the data lives, what happens when a machine dies, and how the cost grows with the number of users. Both skills are tested in interviews, but by different rounds.
System Design vs Software Architecture
Software architecture is the subset of design decisions that are expensive to change later: the service boundaries, which service owns which data, and the way services communicate. System design includes those decisions and continues down to the concrete parts, the data flow, and the numbers. In practice, an architect sets the boundaries, and the system design supplies everything else.
Why Interviews Test System Design
Companies test system design because it predicts how an engineer will make decisions on a real system, which no coding question measures. A system design interview gives you a product, such as a chat application, and about 45 minutes to produce the design described above while explaining each trade-off. The format is described in What is system design in an interview?, and a gentler introduction is in What is system design for beginners?.
How to Prepare
- Learn the five parts in order. Requirements, parts, data model, scaling, and failure. Use the same order on every question so nothing is skipped.
- Attach a number to every non-functional requirement. Availability, latency, and storage each receive a figure before the design starts.
- Design three systems on paper. A URL shortener, a chat application, and a news feed cover most of the patterns.
- Start with the building blocks. Grokking System Design Fundamentals teaches each part named on this page.
- Then practice full questions. Grokking the System Design Interview applies those parts to complete interview questions.

GET YOUR FREE
Coding Questions Catalog

$98

$197

$72