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

┌────────────────────────────────────────────────────────┐
│              Latency Numbers Every Engineer             │
│                  Should Know (Approx.)                  │
├────────────────────────────────────────────────────────┤
│  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

Read QPS  = 200M × 100 / 86,400 ≈ 230,000 reads/sec
Write QPS = 200M × 2 / 86,400   ≈ 4,600 writes/sec

Daily storage = 200M × 2 × 800 bytes ≈ 320 GB/day
Annual storage ≈ 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

┌─────────────────────────────────────────────────────────┐
│               System Design Process                      │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  1. CLARIFY         2. HIGH-LEVEL       3. DEEP DIVE    │
│  ┌──────────┐       ┌──────────┐        ┌──────────┐   │
│  │ Ask      │──────▶│ Draw     │───────▶│ Detail   │   │
│  │ questions│       │ boxes &  │        │ each     │   │
│  │ & scope  │       │ arrows   │        │ component│   │
│  └──────────┘       └──────────┘        └──────────┘   │
│                                                │         │
│                                                ▼         │
│                                          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.