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:

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

1. Conceptual: Explain the difference between scalability and performance. Can a system be performant but not scalable? Give an example.

2. 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?

3. 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.

4. 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