DEV Community

Cover image for System Design Fundamentals
Dhruv Patel
Dhruv Patel

Posted on

System Design Fundamentals

#webdev #programming #software #productivity

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:

User
 ↓
Load Balancer
 ↓
Application Servers
 ↓
Database
 ↓
Cache
 ↓
File Storage
Enter fullscreen mode Exit fullscreen mode

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:

Cart

addItem()

removeItem()

calculateTotal()
Enter fullscreen mode Exit fullscreen mode

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.

1,000,000 × 5 MB
= approximately 5 TB
Enter fullscreen mode Exit fullscreen mode

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:

DAU = 2 million
Enter fullscreen mode Exit fullscreen mode

QPS

QPS means Queries or Requests Per Second.

It tells us how many requests the system receives every second.

If a website receives:

864,000 requests per day
Enter fullscreen mode Exit fullscreen mode

Then approximately:

864,000 ÷ 86,400 seconds
= 10 requests per second
Enter fullscreen mode Exit fullscreen mode

So:

QPS = 10
Enter fullscreen mode Exit fullscreen mode

Storage

Storage tells us how much information must be saved.

For example:

100 million photos
×
3 MB each
=
approximately 300 TB
Enter fullscreen mode Exit fullscreen mode

Bandwidth

Bandwidth represents how much information moves through the network.

For example, if 1,000 people download a 5 MB image:

1,000 × 5 MB
= 5,000 MB
Enter fullscreen mode Exit fullscreen mode

A simple memory trick is:

DAU       → Users
QPS       → Requests
Storage   → Saved data
Bandwidth → Moving data
Enter fullscreen mode Exit fullscreen mode

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:

Latency = 100 ms
Enter fullscreen mode Exit fullscreen mode

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:

10,000 requests per second
Enter fullscreen mode Exit fullscreen mode

is a measure of throughput.

Think:

Latency    → How fast one request finishes
Throughput → How many requests can be handled
Enter fullscreen mode Exit fullscreen mode

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:

Availability → Keep working
Consistency  → Keep data correct
Enter fullscreen mode Exit fullscreen mode

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 location
  • Low latency
  • Availability

Amazon may prioritize:

  • Reliability
  • Scalability
  • Accurate transactions

Because their requirements are different, their architectures will also be different.

That is why there is no single perfect architecture for every application.

There is only a design that best matches the requirements.

A Simple System Design Process

When solving a system design problem, do not immediately start drawing servers and databases.

Use a simple process.

First, understand the requirements.

Ask:

What exactly are we building?
What features are required?
Enter fullscreen mode Exit fullscreen mode

Then estimate the scale.

Ask:

How many users?
How many requests?
How much data?
Enter fullscreen mode Exit fullscreen mode

Next, create the basic architecture.

Think about:

Users
Servers
APIs
Databases
Storage
Cache
Enter fullscreen mode Exit fullscreen mode

After that, identify possible bottlenecks.

Ask:

What happens if millions of users arrive?
Can the database become slow?
What happens if one server crashes?
Enter fullscreen mode Exit fullscreen mode

Then improve the architecture using technologies such as:

Load Balancers
Caching
CDNs
Database Replication
Message Queues
Additional Servers
Enter fullscreen mode Exit fullscreen mode

Continue improving the design while discussing the trade-offs of each decision.

Final Mental Model

You do not need to memorize hundreds of architectures to understand system design.

Remember this flow:

Requirements
      ↓
Estimate Scale
      ↓
Design Architecture
      ↓
Choose Database & Storage
      ↓
Improve Speed with Caching
      ↓
Scale for More Users
      ↓
Find Bottlenecks
      ↓
Discuss Trade-offs
      ↓
Improve the Design
Enter fullscreen mode Exit fullscreen mode

The easiest one-line memory trick is:

System Design = Requirements → Estimate → Architecture → Database → Cache → Scale → Trade-offs → Improve

Once this thinking process becomes natural, designing systems such as Instagram, Uber, Netflix, WhatsApp, or Amazon becomes much easier because the same fundamental ideas appear again and again.

Top comments (0)