System Design
System design is the process of defining the architecture, components, interfaces, and data flow of a software system to satisfy specified functional and non-functional requirements, such as scalability, reliability, and latency. , a URL…
Definition
System design is the process of defining the architecture, components, interfaces, and data flow of a software system to satisfy specified functional and non-functional requirements, such as scalability, reliability, and latency. In interviews, it refers to an open-ended exercise where a candidate designs a large-scale system (e.g., a URL shortener or chat app) while reasoning through trade-offs out loud.
Overview
System design spans two related contexts: it is both a real engineering discipline and a common senior/mid-level interview format. As a discipline, it involves decomposing requirements into services, choosing storage systems, defining APIs, and reasoning about how the system behaves under load, failure, and growth. Core concerns include scalability (horizontal vs. vertical scaling, sharding, load balancing), availability (redundancy, failover, replication), consistency trade-offs (as framed by the CAP theorem), latency, and cost. A typical system design interview starts with clarifying requirements — functional (what the system must do) and non-functional (scale, latency, consistency needs) — before estimating capacity (requests per second, storage volume) and sketching a high-level architecture with clients, load balancers, application servers, caches, databases, and message queues. Candidates are expected to justify choices: SQL versus NoSQL, caching strategy, database sharding key, and how to handle hot spots or single points of failure. Common building blocks recur across problems: load balancers distribute traffic, caches (Redis, Memcached) reduce database load, CDNs serve static content close to users, message queues (Kafka, RabbitMQ) decouple services, and databases are chosen and indexed based on access patterns. Strong answers explicitly state trade-offs rather than presenting a single 'correct' design, since most system design problems have multiple valid solutions depending on which constraints are prioritized. Preparation typically involves studying classic problems (design Twitter, design a rate limiter, design a distributed cache) and the underlying primitives (consistent hashing, replication, partitioning) that recombine across them.
Key Concepts
- Balances functional requirements against scalability, latency, and reliability
- Requires capacity estimation: QPS, storage, and bandwidth calculations
- Uses recurring building blocks: load balancers, caches, CDNs, queues, databases
- Explicitly reasons about trade-offs (CAP theorem, consistency vs. availability)
- Interview format emphasizes communication and justification, not one right answer
- Covers both high-level architecture and deep dives into specific components
- Draws on distributed systems concepts: sharding, replication, consistent hashing