System design rounds feel open-ended because they are. There is rarely one right answer; the interviewer is watching how you reduce ambiguity, make decisions and defend trade-offs. A consistent framework stops you from wandering.
HLD vs LLD: what each round tests
| High-level design (HLD) | Low-level design (LLD) | |
|---|---|---|
| Focus | Components, data flow, scale | Classes, interfaces, patterns |
| Typical prompt | “Design a URL shortener” | “Design a parking-lot system” |
| What you produce | Architecture diagram, APIs, data stores | Class diagram, method signatures |
| Signals | Scalability, reliability, trade-offs | Clean abstractions, SOLID, extensibility |
A 6-step system design interview framework for HLD rounds
- Clarify requirements (about five minutes). Separate functional requirements — what the system does — from non-functional ones such as latency, availability and consistency. Ask who the users are and what the read/write ratio looks like.
- Estimate scale. Rough numbers are enough: daily active users, requests per second, storage per year. Estimates justify the choices you make later.
- Define the API. Two or three core endpoints with request and response shapes. This anchors the rest of the design.
- Sketch the high-level architecture. Clients, load balancer, stateless services, cache, database, queues, object storage. Keep it simple first.
- Deep-dive on the hard parts. Pick the one or two components that make this problem interesting — ID generation for a URL shortener, fan-out for a news feed — and go deep.
- Discuss bottlenecks and trade-offs. Single points of failure, hot partitions, cache invalidation, consistency models. Finish by saying what you would monitor.
Worked example: a URL shortener
Requirements: create short links, redirect quickly, support optional expiry. Reads vastly outnumber writes.
- ID generation: base62-encode a unique ID from a distributed counter or a pre-allocated key range, avoiding collisions without a lookup on every write.
- Storage: a key-value store keyed by short code — a simple access pattern that scales horizontally.
- Reads: put a cache such as Redis in front of the store; popular links will be served almost entirely from cache.
- Redirects: use 301 for permanent links (browser-cacheable) or 302 when you need analytics on every click.
- Analytics: publish click events to a queue and aggregate them asynchronously so redirects stay fast.
A framework for LLD rounds
- List the entities from the requirements. For a parking lot: ParkingLot, Level, Spot, Vehicle, Ticket, Payment.
- Define relationships and responsibilities — who owns what, and which class makes each decision.
- Write the key interfaces and method signatures before any implementation.
- Apply patterns where they earn their place: Strategy for pricing rules, Factory for vehicle types, Observer for spot-availability updates.
- Walk a use case end to end — a car enters, parks, pays and leaves — to prove the design works.
Phrases that keep you in control
- “Before I design anything, can I confirm the scale we’re targeting?”
- “I’ll start simple and evolve it as we find bottlenecks.”
- “There’s a trade-off here between consistency and latency — for this use case I’d choose…”
- “If I had more time, I’d look at…”
Practise five classic prompts — URL shortener, chat app, news feed, rate limiter and file storage — and you will have reusable building blocks for almost anything you are asked.
If you want support during the round itself, Assisting AI explains HLD and LLD concepts as the interviewer speaks — see how it helps in interviews and how answers are structured.
Curious how this works in practice? See Assisting AI’s live transcription and the full call pipeline, step by step.
