Roadmap › 0. Fundamentals › Step 5
HLD
System Design — High-Level Design (HLD) from Basics to Case Studies
How to design large systems — requirements and estimation, scalability and availability, latency vs throughput, CAP and consistency models, load balancing, caching strategies, database choice, replication, partitioning and sharding, consistent hashing, queues and event streaming, rate limiting, search, storage and CDNs, observability, and full case studies (URL shortener, news feed, chat, notification service, e-commerce checkout, file storage, ride booking) with the HLD interview framework.
What it is & where it is used
High-Level Design (HLD) describes a system as boxes and arrows: clients, load balancers, services, databases, caches, queues, storage, and how data flows between them. Low-Level Design (LLD) zooms into one box: classes, interfaces, methods, database tables (next course). System design interviews are mostly HLD for experienced roles, with some LLD.
| Question HLD answers | Example decision |
|---|---|
| How many users/requests/data? | 10M users, 2k requests/s peak, 5 TB/year |
| Which components? | API gateway, stateless services, Redis, SQL + read replicas, queue, CDN |
| Where is data stored and how is it split? | Orders in SQL sharded by customer, images in Blob storage |
| How does it scale and survive failures? | Horizontal scaling, replicas across zones, retries, circuit breakers |
| What are the trade-offs? | Eventual consistency for feeds, strong consistency for payments |
Versions & history
| Era | Milestone in large-scale system design |
|---|---|
| 1990s | Three-tier architecture (presentation, business, data) on single servers |
| 2000s | Web farms + load balancers; memcached (2003); Google papers: GFS (2003), MapReduce (2004), Bigtable (2006) |
| 2007 | Amazon Dynamo paper — eventual consistency, consistent hashing |
| 2008–2012 | Cloud (AWS 2006, Azure 2010); NoSQL (Cassandra, MongoDB, Redis); Kafka (2011) |
| 2012–2015 | Microservices, Docker (2013), Kubernetes (2014); Google Spanner (globally consistent SQL) |
| 2016–2020 | Serverless, managed databases, service meshes, CQRS/event sourcing popular |
| 2020s | Modular monoliths come back for many teams; vector databases and AI workloads; platform engineering |
Lifecycle
The HLD interview framework (≈45 minutes):
- Requirements (5 min) — functional (what users do) and non-functional (scale, latency, availability, consistency, security). Agree on what's out of scope.
- Estimation (5 min) — users, requests/second, read:write ratio, storage per year, bandwidth.
- API design (5 min) — main endpoints with inputs/outputs.
- Data model (5 min) — main entities, choose SQL vs NoSQL, keys and indexes.
- High-level diagram (10 min) — client → CDN → load balancer → services → cache/DB/queue/storage.
- Deep dive (10 min) — 1–2 hard parts the interviewer cares about (feed generation, hot keys, consistency, sharding).
- Wrap-up (5 min) — bottlenecks, failure scenarios, monitoring, how it evolves at 10× scale.
Tools used to develop
- Diagramming: draw.io / diagrams.net, Excalidraw, Lucidchart, Miro, C4 model (context → container → component → code), PlantUML / Mermaid.
- Estimation: latency numbers, powers of two, a calculator.
- Reading: Designing Data-Intensive Applications (Kleppmann), System Design Interview (Alex Xu), High Scalability blog, engineering blogs (Netflix, Uber, Stripe, Microsoft), Azure Architecture Center, AWS Well-Architected.