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 describ