Low Level Design (LLD) rounds are now a standard part of software engineering interviews at Amazon, Google, Flipkart, Swiggy, Uber, and virtually every product company. Yet most engineers have no idea what to practice. This guide cuts through the noise — here are the best LLD problems to prepare, grouped by difficulty, with the key OOP concepts each one tests.
What Is an LLD Interview Round?
In an LLD round (also called Object-Oriented Design or System Design — Low Level), you're given a real-world system and 45–60 minutes to design its classes, relationships, and core algorithms. Unlike High Level Design (HLD) which covers distributed architecture, LLD is about code structure — class diagrams, design patterns, SOLID principles, and interfaces.
Interviewers evaluate you on: can you identify the right entities without over-engineering? Do you apply the Single Responsibility Principle? Can you use patterns like Strategy, Observer, or Factory to make the design extensible? Do you write clean, compilable code under time pressure?
Beginner LLD Problems (Start Here)
If you're new to LLD interviews, start with these. They test fundamental OOP concepts without complex concurrency or algorithmic twists.
1. Parking Lot System
The most classic LLD problem. You need to model floors, slots, vehicles, tickets, and a pricing engine. It tests the Strategy pattern (different pricing per vehicle type), enums, and clean entity separation. Almost every company asks this in some form.Practice the Parking Lot problem on LLD Hub →
Key classes: ParkingLot, Floor, Slot, Vehicle,Ticket, PricingStrategy.
2. Library Management System
Books, members, borrowing records, fines — a clean domain with clear entity boundaries. Tests your ability to model relationships (a member can borrow many books; a book has many copies) and implement search.Practice Library Management →
3. ATM Machine
The ATM problem is deceptively rich. It tests the State pattern (Idle → Card Inserted → PIN Verified → Transaction → Dispensing Cash → Ejecting Card), cash dispensing via theChain of Responsibility pattern, and interface design for bank integrations.Practice ATM Machine →
// State pattern for ATM
interface ATMState {
insertCard(atm: ATM): void;
enterPIN(atm: ATM, pin: String): void;
selectTransaction(atm: ATM, type: TransactionType): void;
dispatchCash(atm: ATM, amount: double): void;
ejectCard(atm: ATM): void;
}
class IdleState implements ATMState {
insertCard(atm: ATM) {
System.out.println("Card inserted");
atm.setState(new CardInsertedState());
}
enterPIN(atm: ATM, pin: String) {
System.out.println("Insert card first");
}
// other methods throw/print "invalid operation"
}4. Elevator System
Design lifts for a building — multiple elevators, floors, and a scheduling algorithm (nearest car or SCAN algorithm). Tests state machines and algorithms.Practice Elevator System →
5. URL Shortener
A URL shortener like bit.ly requires a hash function, redirect logic, expiry management, and analytics. Great for practising clean repository patterns and interface design.Practice URL Shortener →
Intermediate LLD Problems (Most Frequently Asked)
These are the bread-and-butter of LLD interviews at Flipkart, Swiggy, Paytm, PhonePe, and similar companies. Expect at least one of these in your next interview.
6. Splitwise / Expense Splitter
Splitwise is one of the most intellectually demanding LLD problems. You need theStrategy pattern for split types (equal, exact, percentage), a balance tracking system, and a graph minimization algorithm to simplify debts. Asked frequently at fintech companies.Practice Expense Splitter →
// Strategy pattern for split types
interface SplitStrategy {
Map<String, Double> calculateShares(double amount, List<Participant> participants);
}
class EqualSplit implements SplitStrategy {
public Map<String, Double> calculateShares(double amount, List<Participant> p) {
double share = amount / p.size();
Map<String, Double> shares = new HashMap<>();
p.forEach(participant -> shares.put(participant.getUserId(), share));
return shares;
}
}7. Food Delivery System (Swiggy/Zomato)
Restaurant menus, orders, delivery partner assignment, real-time tracking, and ratings. TheObserver pattern is key for real-time status updates. This problem covers a lot of domain breadth — great for practising entity identification.Practice Food Delivery →
8. Movie Ticket Booking (BookMyShow)
Theatres, shows, seats, bookings, payment, and concurrency control (two users booking the same seat simultaneously). One of the best problems for practising locking strategies and state transitions.Practice Movie Ticket Booking →
9. LRU Cache
Implement a Least Recently Used cache with O(1) get and put operations. The classic solution uses aHashMap + Doubly Linked List. This is as much an algorithm problem as a design problem — often asked in SDE-2 interviews to test both skills together.Practice LRU Cache →
class LRUCache {
private int capacity;
private Map<Integer, Node> map = new HashMap<>();
private Node head = new Node(0, 0); // dummy head
private Node tail = new Node(0, 0); // dummy tail
LRUCache(int capacity) {
this.capacity = capacity;
head.next = tail;
tail.prev = head;
}
int get(int key) {
if (!map.containsKey(key)) return -1;
Node node = map.get(key);
moveToFront(node);
return node.val;
}
void put(int key, int val) {
if (map.containsKey(key)) {
Node node = map.get(key);
node.val = val;
moveToFront(node);
} else {
if (map.size() == capacity) evictLRU();
Node node = new Node(key, val);
map.put(key, node);
addToFront(node);
}
}
}10. Chat Application (WhatsApp)
Users, messages, chats (one-to-one and groups), delivery receipts, and online status. TheObserver pattern handles message delivery notifications. Tests modelling of polymorphic entities (chat types).Practice Chat Application →
11. Notification System
Multi-channel notifications (email, SMS, push, in-app). This is a textbook use case for theStrategy pattern (per channel) and the Observer pattern (event-driven dispatch). Also a common backend engineering problem.Practice Notification System →
12. Ride Sharing (Uber/Ola)
Driver and rider matching, fare calculation, trip state machine, surge pricing, and ratings. One of the most comprehensive intermediate problems — touches multiple design patterns and a geo-matching algorithm.Practice Ride Sharing →
13. Rate Limiter
Implement a rate limiter supporting multiple algorithms — Token Bucket, Sliding Window Log, Fixed Window Counter. Frequently asked at API infrastructure and platform teams. Tests clean abstraction and thread safety.Practice Rate Limiter →
Advanced LLD Problems (SDE-2 and Above)
These require deeper design thinking, more entities, or non-trivial algorithms. If you're targeting SDE-2/SDE-3 roles at top-tier companies, practise all of these.
14. Hotel Booking System (OYO)
Rooms, availability calendars, bookings, pricing by season, and cancellation policies. The complexity lies in overlapping reservation detection and dynamic pricing.Practice Hotel Booking →
15. Payment Gateway
Orders, payment methods (card, UPI, wallet), retry logic, refunds, and webhooks. Tests idempotency design, state machines for payment status, and integration patterns with external PSPs.Practice Payment Gateway →
16. Distributed Job Scheduler
Schedule recurring and one-time tasks, with retries, priority queues, worker pools, and at-least-once delivery guarantees. Bridges LLD and HLD — interviewers often use this to pivot into distributed systems.Practice Job Scheduler →
17. Event Ticketing System (Ticketmaster)
Events, venues, seat maps, booking with seat holds (PENDING state during checkout), and concurrent access control. The seat hold pattern is a classic concurrency interview topic.Practice Event Ticketing →
18. Logging Framework
Design a production logging framework with multiple log levels, formatters, and appenders (file, console, remote). The Chain of Responsibility pattern handles log level filtering;Strategy handles formatting. This is asked to test framework design thinking.Practice Logger Framework →
19. Inventory Management
Products, warehouses, stock levels, restocking triggers, and order fulfillment. Tests domain modelling for supply chain with the Observer pattern for low-stock alerts.Practice Inventory Management →
20. Social Media Feed (Twitter/Instagram)
Users, posts, follows, likes, comments, and a feed generation algorithm (pull vs. push model). One of the few LLD problems that naturally bridges into HLD — great for SDE-3 discussions.Practice Social Media Feed →
How to Approach Any LLD Problem in an Interview
Follow this 5-step framework — it works for every problem on this list:
- Clarify requirements (3–5 min): Ask about scale, features in scope vs. out of scope, and edge cases. "Should the parking lot support EV charging slots?" shows depth.
- Identify core entities (3 min): List the nouns from requirements. These become your classes. Avoid anemic models — give each entity behaviour, not just fields.
- Define relationships (2 min): Has-a vs. Is-a. Prefer composition over inheritance. Draw a quick UML in your mind or on the whiteboard.
- Apply design patterns (5 min): Identify which patterns solve the extensibility problems. Strategy for algorithm variants, Observer for event notifications, State for state machines.
- Write code (25–30 min): Start with interfaces and key classes. Write real, compilable code — not pseudocode. Interviewers penalise pseudocode in LLD rounds.
Most Common Design Patterns Across These Problems
If you understand these four patterns deeply, you can handle 80% of LLD interviews:
- Strategy Pattern — used in Parking Lot (pricing), Expense Splitter (split types), Rate Limiter (algorithms), Logger (formatters). Whenever behaviour varies by type, use Strategy.
- Observer Pattern — used in Notification System, Chat App, Food Delivery tracking. Whenever one event should trigger many listeners, use Observer.
- State Pattern — used in ATM, Elevator, Movie Ticket Booking, Payment Gateway. Whenever an entity has distinct phases with different allowed actions, use State.
- Factory Pattern — used in Notification System (channel factory), Logger (appender factory). Whenever creation logic is complex or type-dependent, use Factory.
For a deep dive into patterns with LLD examples, read our Design Patterns for LLD Interviews guide.
SOLID Principles Checklist for LLD Reviews
Before you call your design done in an interview, run through this mental checklist:
- S — SRP: Does each class have exactly one reason to change?
- O — OCP: Can you add a new vehicle type or split strategy without modifying existing classes?
- L — LSP: Do your subtypes behave correctly when substituted for the base type?
- I — ISP: Are interfaces lean? Would any implementor leave a method empty?
- D — DIP: Do high-level classes depend on interfaces, not concrete implementations?
For the full guide, read SOLID Principles for LLD Interviews.
Which Problems Are Asked at Which Companies?
Based on interview reports and community feedback:
- Amazon: Parking Lot, Library Management, Notification System, LRU Cache
- Flipkart / Meesho: Splitwise, Food Delivery, Inventory Management, Payment Gateway
- Swiggy / Zomato: Ride Sharing, Food Delivery, Job Scheduler
- Paytm / PhonePe: Payment Gateway, ATM Machine, Rate Limiter
- Uber / Ola: Ride Sharing, Elevator System, Rate Limiter
- Razorpay / CRED: Payment Gateway, Expense Splitter, Rate Limiter
- Google / Microsoft: LRU Cache, Logger Framework, Chat Application
Frequently Asked Questions (FAQ)
What is Low Level Design in interviews?
Low Level Design (LLD) is a type of interview round where you design classes, interfaces, and relationships for a given system — focusing on Object-Oriented Design, SOLID principles, and design patterns. It differs from High Level Design (HLD) which focuses on distributed architecture, databases, and infrastructure.
Which LLD problem should I start with?
Start with the Parking Lot system. It's beginner-friendly, covers the Strategy pattern, enums, and clean entity separation — and is asked at almost every company. Once comfortable, move to ATM Machine (State pattern) and then Splitwise (multi-pattern + algorithm).
How many LLD problems should I practise before an interview?
Quality over quantity. Practise 10–12 problems deeply — understand the design decisions, can explain the why behind every pattern you use, and can write clean code. Skimming 25 problems without depth won't help. Use AI-scored feedback on LLD Hub to identify weak spots in your solutions.
Do I write code in an LLD interview or just draw diagrams?
At most product companies (Amazon, Flipkart, Swiggy, etc.), you are expected to write actual compilable code — typically in Java or Python. A class diagram alone is not enough. You should write interfaces, key method implementations, and any non-trivial algorithms.
What language should I use for LLD interviews?
Java is the most common choice because its strict typing makes class hierarchies explicit. Python is accepted at most companies. Use whatever language you're most comfortable writing clean OOP code in. Avoid switching languages for interviews.
What is the difference between LLD and HLD?
LLD (Low Level Design) focuses on class diagrams, OOP, SOLID principles, and design patterns — code-level design. HLD (High Level Design) focuses on system components, databases, caching, load balancing, and distributed architecture. Senior roles (SDE-2+) are expected to handle both.
Where to Practice LLD Problems
LLD Hub offers all 20 problems above with AI-scored feedback. Submit your solution in the browser editor and get a score across 5 dimensions: OOP design, SOLID principles, design patterns, code quality, and completeness — the same dimensions real interviewers evaluate. It's the fastest way to identify gaps in your design thinking.
Start with the free problems, then unlock the full set once you're comfortable with the basics. Consistent deliberate practice on these 20 problems is all you need to pass LLD rounds at any product company.