System Design Foundations
Introduction to System Design
System design is the discipline of defining the architecture, components, modules, interfaces, and data flow of a system to satisfy specified requirements. This guide provides a rigorous foundation for reasoning about distributed systems at scale.
- Architecture — The high-level structure of a system and its components
- Trade-offs — Every design decision involves competing constraints
- Scalability — Systems must handle growth in users, data, and traffic
The goal of system design is not perfection—it is making informed decisions under uncertainty.
What Is System Design?
System design is the process of defining the architecture, interfaces, data models, and operational characteristics of a software system to meet functional and non-functional requirements.
Functional vs Non-Functional Requirements
Every system design begins with understanding requirements. These split into two categories:
| Category | Examples |
|---|---|
| Functional | User authentication, search, payments, notifications |
| Non-Functional | Latency < 100ms, 99.99% uptime, support 1M concurrent users, GDPR compliance |
The Core Principles
Several principles guide effective system design:
Principle 1: Know Your Constraints
Before designing anything, understand:
- Scale: How many users? How much data? What growth rate?
- Latency: What are the response time requirements?
- Consistency: How strong are the consistency guarantees?
- Budget: What are the cost constraints?
Principle 2: Design for Failure
Distributed systems fail. Networks partition, disks crash, processes crash. Design every component to be resilient:
- Redundancy at every layer
- Graceful degradation under failure
- Circuit breakers and bulkheads
- Health checks and automatic recovery
Principle 3: Keep It Simple
Complexity is the enemy of reliability. Every additional component, every additional network hop, every additional layer of abstraction introduces failure modes and increases cognitive load.
Principle 4: Make Trade-offs Explicit
Every design decision involves trade-offs. The best engineers can articulate why they chose one approach over another and what they sacrificed.
The Design Process
A systematic approach to system design follows these phases:
Phase 1: Requirements Gathering
Clarify functional and non-functional requirements. Ask questions:
- What are the core use cases?
- What is the expected scale (users, data, QPS)?
- What are the latency requirements?
- What consistency guarantees are needed?
- What are the availability targets?
Phase 2: Back-of-the-Envelope Estimation
Quantify the problem before designing the solution:
Phase 3: High-Level Design
Identify the major components and their interactions:
- Client Layer: Web, mobile, API consumers
- Application Layer: Business logic, orchestration
- Data Layer: Databases, caches, search indices
- Infrastructure Layer: Load balancers, message queues, CDN
Phase 4: Detailed Design
Deep-dive into each component:
- Data models and schemas
- API contracts
- Database selection and partitioning
- Caching strategies
- Communication patterns (sync vs async)
Phase 5: Trade-off Analysis
Document the decisions made and alternatives considered. This is where senior engineers distinguish themselves—not by knowing the "right" answer, but by understanding why a choice was made.
System Design Taxonomy
Systems can be categorized along several dimensions:
Monolithic vs Distributed
Synchronous vs Asynchronous
- Synchronous: Request-response, tight coupling, simpler to reason about
- Asynchronous: Event-driven, decoupled, better for scalability and resilience
Stateless vs Stateful
Key Metrics
System design requires understanding and optimizing for specific metrics:
Amdahl's Law
When optimizing system performance, Amdahl's Law tells us the maximum improvement possible:
The CAP Theorem
One of the most fundamental results in distributed systems:
Practice Exercises
-
Conceptual: Explain the difference between scalability and performance. Can a system be performant but not scalable? Give an example.
-
Estimation: A URL shortener handles 100M new URLs per month and 10:1 read-to-write ratio. Estimate the QPS for reads and writes. How much storage is needed for 5 years at 500 bytes per URL record?
-
Design: Sketch a high-level architecture for a real-time notification system that must deliver messages to 50M users within 500ms. Identify the key components and their responsibilities.
-
Trade-offs: Compare synchronous and asynchronous architectures for processing payment transactions. What are the trade-offs in terms of consistency, latency, and complexity?
What to Learn Next
-> Scalability Fundamentals Vertical vs horizontal scaling, load balancing, and capacity planning.
-> Networking Fundamentals TCP/IP, HTTP, DNS, CDNs, and network latency.
-> API Design REST, GraphQL, gRPC, versioning, and rate limiting.
-> Databases SQL vs NoSQL, indexing, replication, and sharding.
-> CAP Theorem Consistency models, availability, and partition tolerance.
-> Load Balancing Distribution algorithms and L4 vs L7 load balancing.