Introduction to System Design

As you start growing as a developer, eventually you will get this wonderful opportunity to design a system. As a developer you would jump to start visualising the components and implementation details. Trust me, I have been there too!!!

It's much more than that.

Also, to be honest, System Design is not an easy skill to master. You need to practice a lot and learn from real world systems. The good news is, there are people who have mastered this art and have shared their knowledge in books, blogs, videos etc.

To learn System Design, Today is the best day and so let's just get into it..

In simple words, System design is desiging a system that translates business requirements into technical architecture.

Architects all over the world have different approaches to System Design. Once you understand the fundamentals, you are also likely to develop your own approach.

One of the approach I like is to follow this 5-step framework:

1. Requirements Understanding
2. Capacity Planning
3. API Design
4. High-Level Design
5. Deep Dive

In all my upcoming posts, I will be using this framework to design various systems. Trying to design a system with these steps will help you learn the art of System Design.

For this post, let's break down each of these steps.

Requirements Understanding#

First and foremost, we need to understand the requirements. When necessary, ask clarifying questions. Unless all requirements and assumptions are clear, the design may not meet the intended goals.

There are two types of requirements:

Functional Requirements#

In the simplest words - What a system must do.

For example, in a helpdesk ticketing system, creating ticket would be one of the functional requirements. It's something a user would do with the system.

Non-Functional Requirements#

How the system should be. These are the quality attributes of the system. For example, in a helpdesk ticketing system, it should be able to handle 1000 RPS (requests per second) with 99.9% uptime.

Key non-functional requirements include -

• CAP Theorem: Consistency, Availability, Partition Tolerance.
• Scalability: Ability to handle growth in users and data.
• Reliability: System should be available and operational when needed.
• Maintainability: Ease of updates and bug fixes.
• Performance: Speed and responsiveness of the system.
• Security: Protection against unauthorized access and data breaches.

There are many more.. I will cover them in detail in a future post.

Capacity Planning#

Once the requirements are defined, we need to estimate the capacity of the system. There are many ways to estimate the capacity. Here are some of the common metrics -

Active users#

We need to estimate the number of daily active users (DAU) and monthly active users (MAU). When estimating, consider growth over time. For example if we start with 10k monthly active users, we might expect it to grow 10% every month. This helps in planning for scalability.

RPS (Requests per second ) or Throughput#

The active users estimated in previous step will help us to estimate the average requests per second. For example 10k monthly users means around 333 daily users. If we assume 10 requests per user per day, 3330 requests per day divided by 86400 seconds in a day gives us around 0.038 RPS. Looks very small right, may be we should have taken a higher number of MAU/DAU :P.

Data growth#

Estimate how much data the system will generate over time. This includes user data, logs, backups etc. For example if each user generates 1MB of data per month, with 10k users we will have 10GB of data growth per month.

Latency requirements#

Some systems are very sensitive to latency. For example, a real-time chat application should have very low latency (less than 100ms).

Storage requirements#

Although storage these days is very cheap, it is still important to estimate so that sizing of database, caching and backup strategies can be planned accordingly.

API Design#

APIs are the contracts between different components of the system. A well-designed API can make the system more modular, easier to maintain and scale.

While desigining APIs, you have many choices in terms of protocols (REST, GraphQL, gRPC etc.), data formats (JSON, XML, Protobuf etc.) and authentication mechanisms (OAuth, JWT, API keys etc.).

The choice depends on the use case, team expertise and existing infrastructure. In most of your cases, RESTful APIs with JSON payloads are a good starting point.

At start, you may not go into deep details of API design. Just defining the endpoints, request/response formats with key parameters is sufficient. You would refine the API design as you progress with the system design.

High-Level Design#

At this stage, we start visualising the components of the system and how they interact with each other. Start with a simple block diagram showing major components and their interactions. Focus on the core functionality first. Identify key components like databases, caches, load balancers, application servers etc.

At this point you don't have to decide which database to use or which caching strategy to implement. Just focus on the high-level architecture.

Deep Dive#

Once a high-level design is in place, deep dive into the most critical parts of the system. This could be the data flow for a key feature, caching strategy, database schema design or consistency model.

As you deep-dive, you may need to go back to previous steps and refine your design. This is an iterative process.

For this post, this should be enough to get you started with System Design. In the upcoming posts, we will go into details of each step with real-world examples.