System Design Fundamentals
Fast recall
Quick revision
Core answer
Whether you can drive a design from requirements → components → trade-offs (scale, latency, reliability, consistency), naming the forces and the components that resolve them, not just sketch boxes.
Jumping to draw boxes ('we'll use microservices and Kafka') without first deriving the requirements, the scale, and the non-functional forces that justify each component.
Drive design from requirements: state the functional and non-functional (scale, latency, reliability, consistency) requirements, then map each to a component and name the trade-off — this shows you design for the forces, not for the hype.
Interview-ready guide
Interview answer
System design is the high-level design of a whole system — the major components, their responsibilities, and their interactions — and it exists because the cost of getting the high-level structure wrong is enormous; a bad split or data-store choice at the start constrains every feature for years.
The method I always follow is requirements first: functional, what it does, and non-functional, which are the forces — scale or QPS, latency like p99, reliability as SLOs, and consistency strong versus eventual.
Then I map each force to a component and name its cost: a stateless service plus load balancer gives horizontal scale, read replicas give read throughput at the cost of replication lag, a Redis cache gives low latency at the cost of staleness and invalidation, a message queue gives temporal decoupling at the cost of eventual consistency.
Every component resolves a force and adds a cost, so I derive each from a stated requirement rather than reaching for 'microservices and Kafka' by default. The data store I choose by data shape and access pattern — relational, document, key-value, search, time-series — not by default.
And I always do back-of-envelope estimation, because sizing the QPS, storage, and bandwidth tells me which forces actually bite and which components I really need. System design is iterative: every scale pattern solves one bottleneck and introduces a new one, like resharding or cache invalidation.
System Design Fundamentals
Direct Answer
System design (High-Level Design, HLD) is the process of defining a system's architecture — the major components (services, data stores, caches, queues), their responsibilities, and their interactions — to meet functional and non-functional requirements (scale, latency, reliability, consistency). It exists because the cost of getting the high-level structure wrong is enormous: a bad component split or data-store choice made at the start constrains every feature for years, while a good design absorbs growth and failure gracefully. System design is where scalability, reliability, and consistency forces are resolved before code, which is why it's a distinct interview subject.
Common Mistakes & Pitfalls
Jumping to draw boxes ('we'll use microservices and Kafka') without first deriving the requirements, the scale, and the non-functional forces that justify each component.
Check your understanding
Answer these without looking back at the article.
- How do you drive a system design from non-functional requirements, and why is that order important?
- What force does each of these resolve: load balancer, cache, read replica, message queue, shard?
- How does back-of-envelope estimation change the components you choose?
- When is eventual consistency the right choice, and what does it cost the application logic?
- What new bottleneck does each scale pattern introduce (caching, replication, sharding)?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.