What Is High Level Design (HLD)? — System Design Explained
Turn a product idea into a production blueprint: components, data, flows, scale, failures, and trade-offs.
Think of system design like architecting a city before laying a single brick. You wouldn't start building without knowing how many people will live there, where the roads go, and what happens when the power cuts out. High-Level Design (HLD) is that same blueprint for software: it shows how all the big pieces connect before you write any code.
When someone says "build me a Twitter," HLD is the work you do to answer the real questions hiding in that sentence. How many users? Read-heavy or write-heavy? Does every user need to see a post within 1 second or 10 minutes? What data do you store and where? What fails if one server goes down? HLD answers all of these before a single database table is created.
The output of a good HLD is a document showing: the major services, the data stores they own, the APIs they expose, the scale they must handle, the failure modes they tolerate, and the trade-offs you accepted. It is the single artifact that lets a team of 50 engineers build the same thing.
Key concepts
Step-by-step approach
- 1
Write the one-sentence product goal and the user actions it enables.
- 2
List functional requirements in priority order: what the system must do.
- 3
List non-functional requirements with numbers: latency target, availability (4 nines or 5?), durability guarantee, minimum throughput.
- 4
State explicit constraints: team size, delivery timeline, existing infrastructure, compliance rules.
- 5
Identify the two or three flows that are architecturally interesting (critical write path + hot read path).
Key trade-offs
Thoroughness vs. time
A more complete HLD finds more problems early but delays implementation. In 45 minutes, covering 60% of the surface deeply beats covering 100% shallowly.
Reuse vs. isolation
Sharing a database between two services saves operational cost but creates hidden coupling that makes independent deployments impossible.
Consistency vs. developer velocity
Synchronous strongly-consistent flows are easier to reason about but create cascading timeouts. Eventual consistency is harder to test but scales naturally.
Common pitfalls
Jumping to components before requirements: drawing service boxes before writing down the latency target guarantees at least one redesign.
Mixing HLD with LLD: writing API request/response schemas or class hierarchies wastes time and anchors teams to early decisions.
Ignoring non-happy paths: an HLD that only shows the success flow cannot be built reliably.
Interview questions on this topic
Practice answering these with AI feedback → Start on CrackLab
Continue learning — explore 207 more topics on CrackLab DesignHub
From Classic HLD designs (Twitter, YouTube, Uber) to LLD patterns, distributed systems, databases, and company case studies.
Related topics
A repeatable path: clarify, estimate, sketch, choose storage, scale, deep dive, find failures, summarize.
Estimate users, QPS, storage, bandwidth, memory, fanout, and cost before choosing architecture.
Understand response time, work per second, p95/p99, and why averages hide user pain.