System Design is the process of planning how a software system should work before building it.
Think about constructing a large building.
Before workers start putting up walls, architects decide where the rooms, elevators, electricity, water systems, emergency exits, and entrances should go.
Software works in a similar way.
When developers build applications such as Amazon, Instagram, Netflix, Uber, or WhatsApp, they cannot simply start writing code and hope everything works.
They first need to decide how millions of users, servers, databases, files, and requests will work together.
A simple way to remember it is: System Design = The blueprint of a software system.
What Do We Decide in System Design?
During system design, engineers make decisions about things such as: How users connect to the application Where information is stored How different parts of the application communicate How images and videos are stored How the system handles millions of users How the application stays fast How failures are handled How user information stays secure For example, imagine designing WhatsApp.
A user sends a message.
That message must travel to WhatsApp's servers, reach the correct person, possibly be stored temporarily, appear on multiple devices, and trigger a notification.
If millions of people send messages at the same time, the system must continue working without becoming extremely slow or crashing.
That planning is system design.
Why Does System Design Matter?
A good software system should be: Fast Reliable Secure Scalable Affordable to operate Easy to maintain Imagine Instagram without good system design.
Millions of users might open the application at the same time.
Servers could become overloaded, photos might take several seconds to load, comments could disappear, and the application might frequently crash.
System design helps engineers prepare for these situations before they become major problems.
System Design in Software Interviews System design is also common in software engineering interviews.
An interviewer may ask: Design YouTube Design Uber Design Twitter Design WhatsApp Design a URL Shortener The interviewer normally does not expect one perfect answer.
Instead, they want to understand how you think.
They are looking at whether you can: Understand the problem Ask useful questions Estimate the size of the system Choose appropriate technologies Identify possible problems Explain advantages and disadvantages Improve the design when requirements change System design is therefore less about memorizing architectures and more about learning how to make engineering decisions.
High-Level Design and Low-Level Design System design can be viewed at two different levels.
High-Level Design High-Level Design, or HLD, focuses on the big picture.
For example, an application's architecture might look like: At this level, engineers think about major components such as servers, databases, storage, APIs, and caching.
Think of HLD as looking at the map of an entire city.
Low-Level Design Low-Level Design, or LLD, focuses on smaller implementation details.
For example, while building a shopping cart, developers may design: Here the focus is on classes, methods, objects, database structures, and design patterns.
A simple memory trick is: HLD = City map LLD = House blueprint Functional Requirements Functional requirements describe what the application should do.
For WhatsApp, examples could be: Send messages Receive messages Create groups Share photos Delete messages Make calls These are the actual features users interact with.
Think: Functional requirement = What should the system do?
Non-Functional Requirements Non-functional requirements describe how well those features should work.
For example, sending a message is a functional requirement.
But we may also say: The message should arrive within one second.
The service should almost always be available.
Messages should be encrypted.
The system should support millions of users.
These describe the quality of the system.
Think: Functional = What it does Non-functional = How well it does it Estimating the Size of the System Before designing a large system, engineers usually make rough calculations.
This is called back-of-the-envelope estimation.
The goal is not perfect mathematics.
The goal is understanding approximately how large the system might become.
Suppose one million users each upload one 5 MB photo.
Now we know the system may need several terabytes of storage.
Four common estimates are especially useful.
DAU DAU means Daily Active Users.
It tells us how many people use the application each day.
If an application has 10 million registered users but only 2 million use it today: QPS QPS means Queries or Requests Per Second.
It tells us how many requests the system receives every second.
If a website receives: Then approximately: So: Storage Storage tells us how much information must be saved.
For example: Bandwidth Bandwidth represents how much information moves through the network.
For example, if 1,000 people download a 5 MB image: A simple memory trick is: Read-Heavy and Write-Heavy Systems Applications constantly read and write information.
A read means getting existing information.
Examples: Watching a YouTube video Reading a news article Viewing an Instagram post Searching Google A write means creating or changing information.
Examples: Sending a message Uploading a photo Creating an order Updating a bank transaction Some applications are mostly read-heavy.
Instagram, for example, has huge numbers of people viewing posts while a smaller percentage are uploading content.
Other applications can have large amounts of writing.
Messaging systems receive new messages constantly.
Understanding whether a system performs more reads or writes helps engineers choose the right architecture.
Latency and Throughput These two concepts describe system performance.
Latency Latency means how long one operation takes.
If you press the login button and the result appears after 100 milliseconds: Lower latency usually means the application feels faster.
Throughput Throughput means how much work the system can handle within a period of time.
For example: is a measure of throughput.
Think: A highway is a useful analogy.
Latency is how long one car takes to reach its destination.
Throughput is how many cars the highway can handle.
Availability and Consistency Another important system design decision involves availability and consistency.
Availability Availability means the system continues responding when users need it.
For something like a social media feed, displaying information that is a few seconds old may sometimes be acceptable if the application keeps working.
Consistency Consistency means users receive the correct and expected version of the information.
Consider a bank account.
If you transfer $100, your balance should correctly reflect that transaction.
Showing an outdated balance could cause serious problems.
Therefore, banking systems often care strongly about consistency.
A simple way to remember: Different applications may prioritize these differently.
Trade-Offs Trade-offs are one of the most important ideas in system design.
Almost every engineering decision improves one thing while creating another cost.
For example, a cache can make an application much faster.
But cached information may sometimes become outdated.
Database replication can improve reliability.
But maintaining multiple database copies makes the system more complicated.
Compression can reduce file sizes.
But compressing and decompressing information requires additional processing power.
There is rarely a completely free improvement.
Engineers constantly ask: What do we gain, and what does it cost us?
There Is No Perfect System Design Different applications have different priorities.
A bank may prioritize: Security Data accuracy Reliability Netflix may prioritize: Fast video delivery Availability Global performance Uber may prioritize: Real-time lo