What Is System Design?

System design is the process of deciding how different parts of a software system will work together to meet a set of requirements.

It includes decisions about:

• How users interact with the system
• How requests are processed
• Where data is stored
• How different services communicate
• How the system handles increasing traffic
• How it remains available when something fails
• How security, performance and cost are managed

A system could be a small web application, an online store, a messaging platform, a payment service, a video-streaming platform or a global search engine.

The size may change, but the main goal remains the same:

Design a system that solves the required problem while meeting its expected scale, performance, reliability and cost requirements.

A Simple Example

Imagine an online store.

At first, its architecture might contain:

• A website
• One application server
• One database

When a customer searches for a product, the application server receives the request, reads the product information from the database and returns it to the customer.

This may work well for a small number of users. However, as the store grows, new questions appear:

• Can one server handle all the traffic?
• What happens if that server crashes?
• How can frequently viewed products load faster?
• How should product images be stored?
• How can two customers be prevented from buying the final item simultaneously?
• How should payment failures be handled?
• How can emails be sent without slowing down checkout?

System design is the process of answering these questions and turning the answers into a complete technical architecture.

What Does a Software System Contain?

A modern software system may contain many components:

Not every system requires every component. Adding unnecessary components increases complexity and cost.

A strong design includes only the components that are justified by the requirements.

System Design Is More Than Drawing Boxes

System design diagrams often contain boxes connected by arrows. However, drawing an architecture diagram is only one part of system design.

A complete system design should explain:

1. What the system must do
2. How much traffic it must support
3. What data it must store
4. How clients communicate with it
5. How its components work together
6. How it handles failures
7. How it grows with increasing demand
8. What trade-offs were made

For example, placing a cache in a diagram is not enough. The design should also explain:

• What data will be cached
• Why that data should be cached
• How long it will remain cached
• What happens when the cached data becomes outdated
• What happens if the cache becomes unavailable

The important part is not the box itself. The important part is the reasoning behind it.

The Main Goals of System Design

1. Correctness

The system must perform its required functions correctly.

For example, a banking system must not accidentally deduct money twice because a request was retried.

2. Scalability

The system should continue working as traffic, users and data increase.

A system that works for 1,000 users may require a different architecture when serving 100 million users.

3. Availability

The system should remain accessible when users need it.

If one server fails, another server may need to continue handling requests.

4. Reliability

The system should behave correctly and consistently over time, including during failures.

An available system may still be unreliable if it frequently returns incorrect or incomplete results.

5. Performance

The system should respond within an acceptable amount of time.

Performance is commonly measured using:

• Latency
• Throughput
• Requests per second
• Response time
• Resource usage

6. Durability

Data that has been successfully stored should not disappear unexpectedly.

This is especially important for payments, orders, messages and uploaded files.

7. Security

The system must protect users, services and data from unauthorised access and attacks.

Security includes authentication, authorisation, encryption, validation, auditing and abuse prevention.

8. Maintainability

Engineers should be able to understand, test, change and operate the system without excessive difficulty.

9. Cost Efficiency

The architecture should meet the requirements without wasting infrastructure or engineering resources.

The most technically powerful solution is not always the most appropriate solution.

Functional and Non-Functional Requirements

System design begins by understanding the requirements.

Functional requirements

Functional requirements describe what the system must do.

For a messaging application, they might include:

• Users can send messages.
• Users can receive messages.
• Users can view conversation history.
• Users can see whether a message was delivered.
• Users can upload attachments.

Non-functional requirements

Non-functional requirements describe how well the system must operate.

They might include:

• Messages should normally arrive within 500 milliseconds.
• The system should support one million concurrent connections.
• Message history must not be lost.
• The service should remain available during a server failure.
• Communication must be encrypted.

Functional requirements shape the features. Non-functional requirements often shape the architecture.

Two systems may offer the same features but require completely different architectures because their scale, availability or consistency requirements differ.

High-Level and Low-Level System Design

System design is commonly divided into two levels.

High-level design

High-level design describes the system’s major components and how they communicate.

It may cover:

• Clients
• APIs
• Services
• Databases
• Caches
• Queues
• Load balancers
• External systems
• Data flow

High-level design answers:

What are the system’s major building blocks, and how do they work together?

Low-level design

Low-level design focuses on the internal structure of a component.

It may cover:

• Classes and interfaces
• Methods
• Data structures
• Design patterns
• Object relationships
• State transitions
• Error handling
• Concurrency

Low-level design answers:

How should this particular component be implemented and organised?

Both are important, but most traditional system design interviews focus mainly on high-level design.

How System Design Works

A system is normally designed through the following process.

Step 1: Understand the problem

Identify what users need to do and what is outside the scope.

Do not begin by selecting technologies.

Step 2: Gather scale requirements

Estimate:

• Number of users
• Requests per second
• Read and write traffic
• Stored data
• Concurrent connections
• Expected growth

Scale helps determine whether a simple architecture is sufficient.

Step 3: Define the system interface

Decide how clients will interact with the system.

This may include:

• API endpoints
• Request and response structures
• Events
• Error responses

Step 4: Design the data model

Identify:

• Main entities
• Relationships
• Access patterns
• Important indexes
• Consistency requirements

Database selection should follow the data requirements and access patterns.

Step 5: Create the initial architecture

Begin with the simplest design that can support the main use cases.

A basic design might be:

Client -> Application server -> Database

Step 6: Identify bottlenecks

Ask what happens when:

• Traffic increases
• Data becomes very large
• One component fails
• One item becomes extremely popular
• A network request times out
• The system receives duplicate requests

Step 7: Improve the design

Possible improvements include:

• Multiple application servers
• Load balancing
• Caching
• Database replication
• Database partitioning
• Message queues
• Background workers
• Content delivery networks
• Multi-region deployment

Every improvement should solve a specific problem.

Step 8: Explain trade-offs

Most system design decisions have advantages and disadvantages.

For example, caching can reduce latency and database load, but it introduces the risk of serving outdated data.

The goal is not to find a perfect design. The goal is to select reasonable trade-offs for the stated requirements.

Important System Design Trade-Offs

System design is largely about balancing competing goals.

Consistency vs availability

Should every user always see the newest data, or should the service remain available even when some nodes cannot communicate?

Performance vs cost

More servers, larger caches and additional replicas may improve performance, but they also increase cost.

Simplicity vs scalability

A simple monolithic application may be easier to build and operate. Microservices may provide independent scaling but introduce network and operational complexity.

Synchronous vs asynchronous processing

Synchronous processing provides an immediate result but keeps the user waiting. Asynchronous processing improves responsiveness but introduces queues, retries and eventual completion.

Normalisation vs denormalisation

Normalised data reduces duplication. Denormalised data may provide faster reads but makes updates and consistency more difficult.

There is rarely one correct choice for every system. The correct choice depends on the requirements.

System Design vs Software Architecture

The terms are closely related and sometimes used interchangeably.

Software architecture usually describes the broader structural principles of a software product, including its long-term organisation, boundaries and technical direction.

System design often focuses on designing a solution for a specific set of requirements, including components, data flow, scalability and failure handling.

In practice, the two areas overlap significantly.

Common Misunderstandings

“System design means using microservices”

A system can be well designed as a monolith, modular monolith, microservice architecture or serverless application.

The architecture must match the problem.

“More components mean a better design”

Every component creates additional failure cases, deployment work, monitoring requirements and cost.

Unnecessary complexity is a design weakness.

“A specific technology is always the answer”

Technologies are tools. They should be chosen after understanding the requirements and access patterns.

“The system must support billions of users”

Not every system requires global scale. Designing for unrealistic scale can produce an expensive and overly complicated architecture.

“There is one perfect solution”

Most system design problems have several valid solutions. What matters is whether the assumptions, decisions and trade-offs are reasonable.

How to Explain System Design in an Interview

A clear interview definition would be:

System design is the process of defining a software system’s components, data models, interfaces and communication patterns so that it meets its functional requirements and quality goals, such as scalability, availability, reliability, performance, security and cost efficiency.

A simpler version would be:

System design explains how the different parts of a software system work together and how the system handles data, traffic, growth and failures.

After giving the definition, a strong explanation should mention:

• Requirements come first.
• The architecture depends on expected scale.
• Every component should have a purpose.
• Failures must be considered.
• Important decisions involve trade-offs.

Common Interview Mistakes

• Starting to draw before clarifying the requirements
• Choosing technologies without explaining why
• Designing for an unrealistic scale
• Adding caches, queues or microservices unnecessarily
• Ignoring database and data-access patterns
• Ignoring security
• Ignoring component failures
• Describing only the successful request flow
• Claiming that one solution is always best
• Spending too much time on small details
• Remaining silent while drawing
• Finishing without summarising the design

Interview Questions

Basic questions

1. What is system design?
2. Why is system design important?
3. What is the difference between high-level and low-level design?
4. What are functional and non-functional requirements?
5. What makes a system scalable?
6. What is the difference between availability and reliability?
7. Why are trade-offs important?

Deeper questions

1. How would requirements affect database selection?
2. When should a system use asynchronous processing?
3. How would the architecture change if traffic increased by 100 times?
4. How should a system handle partial failures?
5. When would a simple monolith be better than microservices?
6. How would the design change if strong consistency were required?
7. How would cost restrictions affect the architecture?

Key Takeaways

• System design defines how a software system’s parts work together.
• It begins with functional and non-functional requirements.
• It covers components, interfaces, data, communication and infrastructure.
• A good design considers scale, performance, availability, reliability, security and cost.
• High-level design focuses on architecture; low-level design focuses on implementation.
• Every component should solve a clear problem.
• More complexity does not automatically produce a better system.
• Most design decisions involve trade-offs.
• A strong system designer explains both the chosen solution and the alternatives.
• In interviews, the reasoning behind the architecture matters more than drawing a perfect diagram.