Introduction to System Design

System design can feel overwhelming when you’re just starting out, but breaking it down into structured modules makes everything clearer.
On the first day, I learned the foundations of system design using a simple To-Do list application — and this hands-on approach made each concept much easier to understand.

Here is a complete breakdown of everything I learned.

---

1. Requirements Engineering — Start With “What Are We Building?”

Every system design process begins with defining requirements. Using the To-Do app example, I learned how to think in terms of:

Functional Requirements (WHAT the system must do)

For the To-Do app:

• Create a to-do item

• Modify a to-do item

• Complete/mark tasks as done

• Store metadata: title, text, due date

• Private list view for each user

• Sort items by title, date, or text

These are the core features that define the product.

Non-Functional Requirements (HOW the system should behave)

These ensure the system performs well:

• Low latency → tasks load instantly

• High availability → system is always accessible

• Scalability → system can grow with millions of users

Learning to separate functional and non-functional requirements helps anchor discussions during system design interviews.

Understanding System Scale

Before designing anything, you must understand the expected system scale:

• How many users?

• How many daily actions?

• What’s the read/write pattern?

This information becomes the base for all design decisions: capacity, storage, bandwidth, and architecture.

---

2. Capacity Estimation — Understanding the Resources Your System Needs

Capacity estimation is one of the most important skills for system design interviews.
Today I learned how to estimate the load of a To-Do application using three KPIs:

1. Requests

We start by calculating daily write requests:

Daily Write Requests = Active Users × Average Todo Items

Then convert this to Requests Per Second (RPS) using a shorthand:

RPS ≈ Daily Requests / 10^5

Next, calculate read requests using the standard 5:1 read-write ratio:

Read RPS = Write RPS × 5

2. Bandwidth

Bandwidth tells us how much data flows through the system.

Bandwidth = (Read RPS + Write RPS) × Size of Todo Item

Learning this makes it much easier to understand real-world needs like API throughput, network limits, and scaling decisions.

3. Storage Forecasting

Here, we estimate storage needs over the next 5 years.

Storage per second = Write RPS × Size of Todo Item
Storage in 5 years ≈ Storage per second × 2 × 10^8

For our example, the result was around:

👉 400 GB of storage required over five years

This shocked me because it shows how quickly even a simple app can grow.

---

3. Data Modeling — Structuring Data the Right Way

Data modeling is the heart of every system design conversation.

The process:

Step 1: Identify Entities

For the To-Do app:

• User

• To-Do Item

Step 2: Define Attributes

User

• id

• name

• email

• created_at

To-Do Item

• id

• title

• text

• due_date

• is_completed

• user_id (relationship)

• created_at

Step 3: Define relationships

• One User → Many To-Dos

• To-Dos belong to a single User

Why Data Modeling Matters

It helps you:

• Choose the right database

• Understand query patterns

• Optimize storage

• Plan indexing strategies

• Avoid performance bottlenecks

This module clarified why database decisions are impossible without a clean data model.

---

4. API Design — Creating a Technical Contract Between Client & Server

API design is where the application becomes usable.

For the To-Do app, we learned the four essential endpoints:

1. Create To-Do

2. Get User To-Dos

3. Update To-Do

4. Complete/Delete To-Do

Key Input Parameters

• User ID → retrieve only their tasks

• Sort options → by title, text, or due date

• Page number → pagination for large lists

Response Structure

A proper response includes:

• List of items for the requested page

• Metadata (page number, next page)

• Sorted results based on user input

Design Methodology

We followed a structured method:

1. Revisit functional requirements

2. Distill API goals

3. Define inputs

4. Define outputs

5. Ensure all expectations are aligned

This mirrors what interviewers expect during system design rounds.

---

5. Putting It All Together — System Design Fundamentals

The final module tied everything into a full system design.
Using the To-Do app, we integrated:

• Requirements engineering

• Capacity estimation

• Data modeling

• API design

The module emphasized:

Best practices

• Always clarify requirements first

• Communicate assumptions clearly

• Keep the design simple before scaling

• Prioritize user experience (low latency)

• Think about reliability (high availability)

Technical Contract

A well-designed API becomes a contract between client and server.
This clarity avoids conflicts and reduces bugs.

By completing all modules today, I saw exactly how each part of system design builds on the previous one — just like in real-world engineering.

---

Conclusion

This introduction highlighted the complete flow of system design:

1. Define requirements

2. Estimate system load

3. Model data

4. Design APIs

5. Build a scalable architecture

Using a simple To-Do list app made everything intuitive and easy to visualize.

This is just part one, but I bet you are already feeling confidence in understanding scalable systems and preparing for system design interviews.