Introduction to System Design

System design is the process of defining the architecture, components, modules, interfaces, and data flow for a system to satisfy specified requirements. Whether you are preparing for interviews or building real-world products, understanding system design fundamentals is essential.

---

Why System Design Matters

Modern software rarely runs on a single machine. Even a simple web application typically involves:

• Web servers handling HTTP requests
• Databases storing persistent data
• Caches reducing latency
• Load balancers distributing traffic
• CDNs serving static assets globally

Understanding how these pieces fit together is what separates developers who build prototypes from engineers who build products that serve millions.

---

Functional vs Non-Functional Requirements

Every system design starts with requirements gathering. There are two categories:

Functional Requirements

These describe what the system should do:

• Users can create an account and log in
• Users can post messages up to 280 characters
• Users can follow other users
• Users see a timeline of posts from people they follow

Non-Functional Requirements

These describe how well the system should perform:

Requirement	Description	Example
Scalability	Handle growing load	100M daily active users
Availability	Uptime percentage	99.99% (52 min downtime/yr)
Latency	Response time	p99 < 200ms
Consistency	Data correctness	Strong or eventual
Durability	Data is not lost	No data loss on failure
Security	Protection from threats	Encryption at rest/transit

Tip: Non-functional requirements often drive the most important architectural decisions. Two systems with identical features can have completely different architectures based on their scale and latency requirements.

---

Back-of-the-Envelope Estimation

Before diving into design, estimate the scale of the system. This helps you choose appropriate technologies and architectures.

Key Numbers to Know

Operation	Approx. latency
L1 cache reference	0.5 ns
Branch mispredict	5 ns
L2 cache reference	7 ns
Mutex lock/unlock	25 ns
Main memory reference	100 ns
SSD random read	150 μs
Read 1 MB sequentially from memory	250 μs
Round trip within same data centre	500 μs
Read 1 MB sequentially from SSD	1 ms
HDD seek	10 ms
Read 1 MB sequentially from HDD	20 ms
Send packet US-East → US-West	40 ms
Send packet US → Europe	80 ms
Send packet US → Australia	150 ms

Estimation Walkthrough: Twitter-Like Service

Assume:

• 500 million users, 200 million daily active users (DAU)
• Each user views 100 tweets/day and writes 2 tweets/day
• Average tweet size: 280 bytes text + 500 bytes metadata = ~800 bytes

$$\begin{aligned} \text{Read QPS} &= 200\text{M} \times 100 / 86{,}400 \approx 230{,}000 \text{ reads/sec} \\ \text{Write QPS} &= 200\text{M} \times 2 / 86{,}400 \approx 4{,}600 \text{ writes/sec} \\[4pt] \text{Daily storage} &= 200\text{M} \times 2 \times 800 \text{ bytes} \approx 320 \text{ GB/day} \\ \text{Annual storage} &\approx 320 \text{ GB} \times 365 \approx 117 \text{ TB/year} \end{aligned}$$Read QPSWrite QPSDaily storageAnnual storage​=200M×100/86,400≈230,000 reads/sec=200M×2/86,400≈4,600 writes/sec=200M×2×800 bytes≈320 GB/day≈320 GB×365≈117 TB/year​

Tip: You do not need exact numbers. The goal is to determine the order of magnitude — thousands vs millions vs billions of operations per second.

---

The Design Process Framework

Use a structured approach when tackling any system design problem:

Step 1: Clarify Requirements (5 minutes)

• Ask questions about scope
• Identify core features vs nice-to-haves
• Determine scale (users, data volume, read/write ratio)
• Clarify non-functional requirements

Step 2: High-Level Design (10 minutes)

• Draw the major components
• Show how data flows between them
• Identify APIs and interfaces

Step 3: Deep Dive (20 minutes)

• Explore each component in detail
• Discuss database schema
• Address bottlenecks and scaling
• Consider failure scenarios

Step 4: Wrap Up (5 minutes)

• Summarise trade-offs
• Discuss monitoring and alerting
• Mention future improvements

graph LR
  A["1. Clarify: ask questions & scope"] --> B["2. High-level: draw boxes & arrows"]
  B --> C["3. Deep dive: detail each component"]
  C --> D["4. Wrap up: trade-offs & next steps"]

---

Common System Design Building Blocks

Before we dive deeper in later lessons, here is a quick overview of the main building blocks:

Component	Purpose
Load Balancer	Distributes requests across servers
Web Server	Handles HTTP requests
Application Server	Runs business logic
Database	Persistent storage (SQL or NoSQL)
Cache	Fast in-memory storage for hot data
CDN	Serves static content close to users
Message Queue	Asynchronous communication between services
Search Index	Full-text or structured search
Object Storage	Large files (images, videos, backups)
API Gateway	Entry point for client requests

---

Summary

• System design is about defining architecture and trade-offs to meet requirements.
• Always start by clarifying functional and non-functional requirements.
• Use back-of-the-envelope estimation to understand the scale before designing.
• Follow a structured four-step process: clarify, high-level design, deep dive, wrap up.
• The rest of this course explores each building block in depth, giving you the knowledge to design reliable, scalable systems.