You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
Introduction to System Design
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.