HLD · Roadmap
High-Level Design
Scale from a single server to globally distributed systems. Master the building blocks — networking, databases, caching, queues, consistency, and resilience — then put them together on the classic system-design interview problems, from a URL shortener to a global ride-sharing platform.
Your progress
0 / 181 topics
Progress saves automatically in this browser — check topics off as you learn them.
What system design actually is, the vocabulary of trade-offs, and the napkin math you'll use in every single problem.
Outcome — Frame any problem in terms of requirements and constraints, and estimate scale before drawing a single box.
How bytes actually move between machines — the protocols and API styles every distributed system is built on.
Outcome — Choose the right communication style (REST, gRPC, WebSockets…) and explain what happens from URL to response.
The network stack
API & communication styles
The first moves you make when one server is no longer enough — spreading load across many.
Outcome — Take a single-server app and scale it horizontally behind a load balancer and a CDN.
The single most important decision in most designs: where and how the data lives.
Outcome — Pick the right database type for a workload and justify SQL vs NoSQL with confidence.
Relational foundations
NoSQL & storage types
Under the hood
When one database can't keep up, you replicate it for reads and shard it for writes — each with sharp edges.
Outcome — Design a data tier that survives node failure and scales past a single machine's limits.
The highest-leverage performance tool there is — and the one with the most famously hard problem (invalidation).
Outcome — Place caches at the right layers, choose read/write strategies, and avoid stampedes and stale data.
The hard truths of running across many unreliable machines — the theory that explains why distributed design is hard.
Outcome — Reason precisely about consistency, availability, and agreement when nodes and networks fail.
The fundamental trade-offs
Agreement & coordination
Time, ordering & detection
Decouple work in time — accept now, process later — the backbone of resilient, scalable systems.
Outcome — Design event-driven flows with queues and streams, and reason about delivery guarantees.
How to slice a system into services — and the patterns that keep that slicing from becoming a distributed mess.
Outcome — Argue monolith vs microservices on the merits, and apply the right structural pattern.
Everything fails eventually — design so that a failed part degrades gracefully instead of taking the system down.
Outcome — Build systems that bend instead of break, and put real numbers on availability.
You can't operate what you can't see — and you can't move fast without safe ways to ship.
Outcome — Instrument a system end to end and ship changes without taking it down.
Observability
Delivery & infrastructure
The cross-cutting concern interviewers expect you to bring up unprompted — at least at the edges.
Outcome — Reason about authn/authz, protect data in transit and at rest, and name the common attack surfaces.
Specialized building blocks for search-heavy and data-heavy systems — and the probabilistic tricks that make scale affordable.
Outcome — Add full-text search, geo-queries, and analytics pipelines to a design when the problem calls for them.
Search & geo
Data & analytics
Probabilistic structures
A repeatable structure so you never freeze at the whiteboard — drive the conversation instead of being driven.
Outcome — Walk into any open-ended design round with a step-by-step method and the language to defend your choices.
Where it all comes together — the canonical problems, from a warm-up URL shortener to a globally distributed platform.
Outcome — Confidently design any of the famous interview systems end to end, on the clock.
Warm-ups & infrastructure
Social, feed & messaging
Media, location & marketplace
Commerce, payments & analytics