System Design Interview Questions,
and What to Actually Cover
14 high-level and low-level design problems you can practise, each with what the interviewer is testing and the points a strong answer covers. Plus a step-by-step approach for the round.
How to approach any system design question
Interviewers grade the process as much as the final diagram. Work through these steps in order, out loud.
- Clarify requirements. Ask what the system must do (functional) and how well (scale, latency, availability, consistency). Write both lists down before drawing anything.
- Estimate the scale. Rough users, requests per second, read/write ratio and storage per year. You need orders of magnitude, not precision.
- Define the API. The handful of endpoints or events the system exposes. This pins down what you're actually building.
- Model the data. Main entities, how they relate, and which access patterns decide the choice of database.
- Draw the high-level design. Clients, load balancer, services, databases, caches and queues, and the request path through them.
- Go deep on the hard part. Pick the one or two components that make this problem hard (the hot path, the consistency problem, the fan-out) and design them properly.
- Discuss trade-offs and failures. What breaks first as load grows, what happens when a component fails, and what you'd change at 10× scale.
High-level design (HLD) questions
Usual for senior, lead and staff interviews. Several are framed around systems Indian users know well, which makes the requirements easier to reason about.
HLD 1. Design a UPI-style peer-to-peer payment system
What it tests: Consistency and correctness under failure: money must never be lost or double-spent.
- Idempotency keys on every payment request
- A ledger with double-entry records instead of updating balances in place
- Handling timeouts from the bank or switch: pending states and reconciliation
- Exactly-once effects on top of at-least-once messaging
HLD 2. Design a food delivery app's order and rider-assignment system
What it tests: Real-time location data, matching, and state machines across three parties.
- Order lifecycle as an explicit state machine
- Storing and querying rider locations (geohash or similar spatial index)
- Assignment logic and what happens when a rider rejects
- Pushing live status to customer, restaurant and rider
HLD 3. Design live video streaming for a cricket final with tens of millions of viewers
What it tests: Read-heavy scale, CDNs and sudden traffic spikes.
- Ingest, transcoding to multiple bitrates, and adaptive streaming
- CDN edge caching and origin shielding
- Pre-scaling for a known spike versus autoscaling
- Live concurrency counts without hammering a single counter
HLD 4. Design a train ticket booking system that survives the opening-minute rush
What it tests: Contention on a small, fixed inventory under a massive burst.
- Seat inventory locking: pessimistic, optimistic, or reservation with expiry
- A virtual waiting room or queue in front of booking
- Keeping payment and seat hold consistent
- Protecting the system from bots and retries
HLD 5. Design a notification service (SMS, email, push) for OTPs and marketing
What it tests: Asynchronous pipelines, priorities and third-party providers.
- Separate priority queues so OTPs never wait behind a marketing blast
- Retries with backoff and failover between providers
- Rate limits per user and per provider
- Templates, user preferences and delivery tracking
HLD 6. Design a flash sale for an e-commerce site
What it tests: Inventory correctness and spike handling at checkout.
- Decrementing stock atomically (Redis or database with conditional updates)
- Holding stock during payment with a timeout
- Caching product pages aggressively while keeping stock live
- Graceful degradation when the spike exceeds capacity
HLD 7. Design a chat app with one-to-one and group messages
What it tests: Persistent connections, ordering and offline delivery.
- WebSocket gateways and routing a message to the right connection
- Message ordering per conversation and delivery/read receipts
- Storing messages for offline users and syncing on reconnect
- Group fan-out: on write versus on read
HLD 8. Design a URL shortener with analytics
What it tests: The classic warm-up: key generation, read-heavy caching and simple analytics.
- Generating short, unique keys (counter with base62, or pre-generated keys)
- Redirect path served from cache
- Recording clicks asynchronously so redirects stay fast
- Custom aliases and expiry
Interviewing soon? The Interview Playbook builds a design scenario from your actual JD, matched to its domain, seniority and company type.
Free account · 10 seconds with Google sign-in
Low-level design (LLD) questions
Usual for junior, SDE-1 and SDE-2 interviews. Expect to write class diagrams or actual code, and to defend your design choices.
LLD 1. Design a parking lot
What it tests: Object modelling, responsibilities and extensibility.
- Classes for lot, floor, spot, vehicle and ticket
- Different spot and vehicle types without a giant if/else
- Pricing as a pluggable strategy
- Concurrency when two cars take the last spot
LLD 2. Design an expense-sharing app like the ones friends use to split bills
What it tests: Domain modelling and a clean algorithm for settling up.
- Users, groups, expenses and splits (equal, exact, percentage)
- Balance sheet updates per expense
- Simplifying debts to the fewest transactions
- Keeping split types extensible
LLD 3. Design a movie ticket booking system
What it tests: Modelling plus concurrency on seat selection.
- Movies, theatres, screens, shows and seats
- Temporarily locking seats during payment
- Releasing locks on timeout or failure
- Clear interfaces between booking, payment and notification
LLD 4. Design an elevator system for a building
What it tests: State machines and scheduling logic.
- Elevator state: direction, current floor, door state
- Handling requests from inside the car and from floors
- A scheduling strategy and how to swap it
- Edge cases: overload, maintenance mode, emergency
LLD 5. Design a rate limiter
What it tests: Algorithms and thread safety.
- Token bucket versus fixed and sliding windows
- Per-user and per-API limits
- Thread-safe counters
- How it would extend to a distributed setup
LLD 6. Design an in-memory LRU cache
What it tests: Data structures and complexity.
- Hash map plus doubly linked list for O(1) get and put
- Eviction on capacity
- Thread safety
- Adding TTL expiry
Common traps
- Drawing boxes before agreeing on requirements and scale.
- Naming technologies ("use Kafka") without saying why this problem needs them.
- Spending the whole round on the easy parts and running out of time before the hard one.
- Ignoring failure: what happens when the database, a queue or a third party goes down.
- Designing for Google scale when the interviewer gave you a startup's numbers.
Practise the question you'll actually get
Paste the JD you're interviewing for. Your Interview Playbook flags what they'll grill you on, and the full Playbook adds a system design scenario built for that role.
Build My Playbook — FreeFrequently asked questions
What's the difference between LLD and HLD interviews?
Low-level design (LLD) is about code structure: classes, interfaces, relationships and design patterns for a contained problem like a parking lot. High-level design (HLD) is about distributed systems: services, databases, caches, queues and the trade-offs of running them at scale. Junior and SDE-1/SDE-2 interviews lean towards LLD; senior and above lean towards HLD.
How long is a system design round?
Usually 45 to 60 minutes. Budget about 5–10 minutes on requirements and estimates, 10–15 on the API, data model and high-level design, and the rest on the deep dive and trade-offs.
How should I prepare for a system design interview?
Learn one structured approach (like the seven steps on this page) and practise it out loud on a timer with 10–15 problems, covering both read-heavy and write-heavy systems. Then prepare for the role in front of you: the scale of that company, its domain, and the systems you've built yourself, because interviewers often ask you to design something close to your own past work.
Do I need to know specific technologies like Kafka or Cassandra?
You need to know what kinds of tools exist and when you'd use each: a message queue, a wide-column store, a cache, a search index. Being able to justify a choice matters more than knowing one product in depth. If you name a technology, be ready to explain why it fits this problem.
Can I get a system design question tailored to my interview?
Yes. Switchly's Interview Playbook builds a system design scenario from the actual JD you're interviewing for, using its domain, seniority and company type (startup, MNC or GCC), and gives low-level design for junior roles and high-level design for senior ones. It's part of the full Playbook; your first Playbook preview is free.