System Design Interview Basics
System design interviews ask you to design a large-scale distributed system (like "Design Twitter" or "Design Uber"). These questions are open-ended, ambiguous, and test your ability to analyze requirements, make trade-offs, and define architecture.
1. A 4-Step Framework
Step 1: Understand the Problem & Establish Design Scope
Don't jump into drawing boxes immediately. Ask questions to clarify requirements.
- Functional Requirements: What does the system actually do? (e.g., Users can post tweets, follow others).
- Non-Functional Requirements: Scalability, Latency, Consistency, Availability. (e.g., System must handle 100M DAU).
- Constraints: Traffic volume, read/write ratio.
Step 2: Propose High-Level Design
Draw a diagram representing the core components and how data flows between them.
- Clients (Mobile/Web)
- Load Balancer
- Web Servers (API)
- Database
- Cache
Step 3: Design Deep Dive
Identify bottlenecks and scale the system.
- Scaling: Vertical vs Horizontal.
- Database: SQL vs NoSQL? Sharding? Replication?
- Caching: Where to cache? (CDN, Redis).
- Async Processing: Message queues for heavy lifting.
Step 4: Wrap Up
- Discuss potential bottlenecks.
- How would you monitor the system?
- Summary of trade-offs made.
2. Key Concepts to Master
- Scalability: Horizontal vs Vertical scaling.
- Reliability & Availability: Redundancy, failover.
- Consistency Patterns: Strong vs Eventual consistency (CAP Theorem).
- Data Partitioning: Sharding strategies.
3. Back-of-the-Envelope Calculations
You often need to estimate storage or bandwidth requirements.
- Powers of Two: $2^{10} \approx 10^3$ (1KB), $2^{20} \approx 10^6$ (1MB), $2^{30} \approx 10^9$ (1GB).
- Latency Numbers:
- L1 cache: 0.5 ns
- Main memory ref: 100 ns
- Disk seek: 10,000,000 ns (10 ms) -> Disk is slow!
programming/distributed-systems programming/load-balancing programming/caching-strategies programming/database-basics