HLD vs LLD | Common System Design Questions
HLD and LLD are not two names for the same interview - they are two different rounds testing two different skills, and prepping for the wrong one is how people walk in confident and walk out confused. High-Level Design (HLD) is about system architecture: the boxes, the services, the databases, and how the whole thing scales. Low-Level Design (LLD) is about code: the classes, the relationships, the design patterns, and clean object-oriented structure. HLD is "the what," LLD is "the how." This post lays out the difference and gives you the catalog of problems commonly asked in each, so you practice the right thing.
This is part of the System Design Guide series. The scoping and framework posts so far are about the HLD round; here we zoom out to place HLD and LLD side by side, because you need to know which one you're walking into.
The split in one line
| HLD (High-Level Design) | LLD (Low-Level Design) | |
|---|---|---|
| Also called | Macro / system design | Micro / detailed design, machine coding, OOD |
| Focus | Architecture: components, services, data flow | Code: classes, methods, objects, relationships |
| Main concern | Scalability, availability, latency, consistency | Maintainability, extensibility, clean OOP |
| Key tools | Load balancers, caches, queues, sharded DBs, CDNs | SOLID principles, design patterns, UML class diagrams |
| Deliverable | An architecture diagram + tech choices | Working, extensible code (or a class diagram) |
| Interview format | Whiteboard/verbal, ~45-60 min, open-ended | Machine coding / pair programming, 60-120 min |
| Audience it maps to | Architects, stakeholders | Developers building the module |
| Example | "Design Twitter" -> feed service, fanout, cache | "Design a parking lot" -> Vehicle, Spot, Ticket classes |
The tell: if the answer is a diagram of services talking to each other, it's HLD. If the answer is a set of classes with methods and you might have to actually run the code, it's LLD.
What the HLD round is testing
An HLD interview hands you a vague, broad prompt ("design a URL shortener," "design a chat app") and watches how you turn it into a scalable architecture. It follows the classic flow: scope the requirements, sketch the high-level components, then deep-dive the hard part. What it's really probing:
- Can you reason about scale - QPS, storage, read vs write ratios - and size a system to it?
- Do you know the building blocks and when to reach for each: caching, replication, sharding, load balancing, message queues, CDNs?
- Can you make and defend trade-offs - strong vs eventual consistency, SQL vs NoSQL, push vs pull?
This is distributed-systems thinking. Concepts like CQRS for splitting read and write paths, or presigned URLs for moving media off your servers, are the vocabulary of the HLD round. The framework, time management, and requirement-gathering covered earlier in this series are all HLD skills.
What the LLD round is testing
An LLD interview (often a machine coding round at companies like Amazon, Uber, Swiggy, Flipkart, Razorpay, and PhonePe) hands you a self-contained problem ("design a parking lot," "build a Splitwise") and expects clean, working, extensible code in 60 to 120 minutes, followed by a review where you defend your class design. What it's really probing:
- Can you model a domain as classes and relationships - inheritance vs composition, clear responsibilities?
- Do you apply the SOLID principles so the code is open to extension without rewrites?
- Do you know the design patterns and apply them where they fit rather than forcing them?
Four patterns carry most LLD interviews - Strategy, State, Observer, and Factory. Strategy shows up almost everywhere (pricing, allocation, dispatch); State runs vending machines and order lifecycles; Observer drives notifications; Factory creates the right object without hard-coding types. Learn those four deeply and you're ready for the majority of problems. This is where writing idiomatic, well-structured code in your language matters - the same instincts covered in the idiomatic Golang apply to any LLD, in any language.
A common LLD trick worth knowing: for anything time-driven or mechanical (an elevator, a scheduler), you usually simulate time yourself with a step() or tick() loop rather than dealing with real threads and hardware - it keeps the problem tractable in the time you have.
Common HLD problems
These are the recurring high-level design prompts, grouped by the core challenge each one centers on. Most map to a chapter in Alex Xu's System Design Interview, and you can practice more from the system design primer.
| Category | Problems |
|---|---|
| Storage & IDs | URL shortener (TinyURL), Pastebin, key-value store, unique ID generator, consistent hashing |
| Files & media | Google Drive / Dropbox, YouTube / Netflix (video streaming) |
| Social & feeds | Design Twitter / news feed, Instagram, nearby friends / proximity (Yelp) |
| Messaging | Chat app (WhatsApp / Messenger), notification system |
| Search | Search autocomplete / typeahead, web crawler |
| Infra building blocks | Rate limiter, distributed message queue, distributed cache |
| Real-time & transactions | Uber / ride-hailing, Ticketmaster booking, payment system, ad click aggregation, stock exchange |
The skill being graded is the same across all of them: gather requirements, do the back-of-the-envelope math, propose an architecture, and defend the trade-offs.
Common LLD problems
LLD problems are self-contained domains you model in code. Start with the Tier 1 list - Parking Lot is the single most-asked - then move to Tier 2 for senior-level depth (concurrency, transactions).
| Tier | Problem | Patterns it exercises |
|---|---|---|
| 1 - must practice | Parking Lot | Strategy (allocation/pricing), Factory, State |
| 1 | Snake and Ladder | State, turn management |
| 1 | Vending Machine | State |
| 1 | Elevator System | State, Strategy (dispatch), simulation with ticks |
| 1 | Tic-Tac-Toe / Chess | State, Strategy |
| 1 | Movie Ticket Booking (BookMyShow) | Strategy (pricing), locking/concurrency |
| 1 | Splitwise | Composition, balance graph modeling |
| 1 | Logging Framework (log4j) | Chain of Responsibility, Decorator |
| 1 | LRU / LFU Cache | Data-structure design (hashmap + linked list) |
| 1 | Rate Limiter | Strategy (token bucket, sliding window) |
| 2 - senior | Food delivery (Swiggy / Zomato) | Observer, State, matching |
| 2 | Wallet / payments (Paytm / PhonePe) | Command, transaction safety, idempotency |
| 2 | Notification service | Observer, Template Method, Factory |
| 2 | ATM | State, transaction handling |
| 2 | Library management / online bookstore | Domain modeling, relationships |
| 2 | Meeting scheduler / calendar | Interval handling, conflict detection |
Notice the pattern column repeats: Strategy, State, Observer, and Factory really do cover most of these. If your time is limited, drill those four against Parking Lot and Vending Machine first.
The problems that appear in both
A few prompts show up in both rounds, and the difference is entirely the altitude:
- Rate limiter - in HLD you design a distributed, low-latency limiter shared across servers (where does it live, Redis-backed counters, fault tolerance). In LLD you write the classes and the token-bucket/sliding-window algorithm.
- Notification system - HLD is the queue, fanout, delivery, and retry architecture; LLD is the
NotificationManagerwithEmailChannel/SMSChannelclasses wired via Observer and Factory. - URL shortener - HLD is the hashing, storage, and read-heavy caching at scale; LLD is the encoder class and the key-generation logic.
Same words, different interview. Always confirm which altitude the interviewer wants before you start.
Which round are you in?
Read the prompt and the constraints, and it usually gives itself away:
- Words like "scale," "millions of users," "high availability," "distributed" and a request for a diagram -> HLD. Reach for the requirements-and-architecture framework.
- Words like "design the classes," "write working code," "extensible," "we'll run it," a shared code editor, and a 90-minute block -> LLD. Reach for SOLID and your four core patterns.
If it's genuinely unclear, ask - "are you looking for the high-level architecture, or the class design and working code?" is a perfectly good clarifying question, and getting it right is the whole game.
You now know which interview to prep
HLD is architecture, scale, and trade-offs; LLD is classes, patterns, and clean code. They share a few problem names but test different muscles, so practice them separately: run the HLD catalog through the requirements-and-architecture framework, and drill the LLD catalog with SOLID and the Strategy/State/Observer/Factory patterns against Parking Lot first.
This series continues on the HLD track - taking a scoped problem and turning it into the high-level design, step by step. If your upcoming loop has a machine coding round, treat the LLD catalog above as a separate practice list and time yourself: working code in 90 minutes is its own skill.