Top 25 LLD Interview Questions and Answers (2025)

These are the 25 Low-Level Design questions that show up most often across interview reports from Google, Amazon, Meta, Flipkart, Swiggy, Uber, Ola, CRED, Razorpay, and other top product companies. The ranking below reflects real frequency, not just popularity on paper -- if you can only prepare a subset before an interview, work top to bottom.

Rather than skim 25 shallow summaries, go deep on the first handful. Interviewers reuse the same underlying patterns -- State, Strategy, Factory, Observer -- across almost every question on this list, so mastering how they apply to a Parking Lot or an LRU Cache transfers directly to a dozen other prompts you haven't seen yet.

01The Top LLD Questions

1. Design a Parking Lot System

Frequency: Very high | Companies: Amazon, Google, Flipkart. This is the single most-asked LLD question in the industry -- almost every machine-coding round includes some variant of it, because it packs inheritance, composition, and concurrency into one deceptively simple domain.

• Core entities: ParkingLot, ParkingFloor, ParkingSpot, Vehicle (Car / Bike / Truck), Ticket, Payment
• Key patterns: Factory (creating vehicle types), Strategy (pricing rules by spot type or duration), Singleton (a single ParkingLot instance), Observer (display boards reacting to occupancy changes)

The detail that separates a strong answer from a mediocre one is how ParkingSpot decides what it can hold. Don't hardcode a switch on vehicle type inside the spot -- model spot compatibility as data (a SpotType that knows what it accommodates()) so adding a new vehicle or spot size never touches existing classes. This is the cleanest test of the Open/Closed Principle in the whole question, and interviewers probe it hardest.

public class ParkingSpot {
  private SpotType type;
  private boolean occupied;
  private Vehicle currentVehicle;

  public boolean canFit(Vehicle vehicle) {
    return !occupied && type.accommodates(vehicle.getType());
  }

  public void parkVehicle(Vehicle vehicle) {
    this.currentVehicle = vehicle;
    this.occupied = true;
  }
}

Practice this one: Design a Parking Lot on LLDCanvas - full brief, staged hints, and a live UML canvas.

2. Design an LRU Cache

Frequency: Very high | Companies: Google, Amazon, Uber. Less about class modeling and more about picking the right two data structures and wiring them together correctly under time pressure.

• Core structure: a HashMap for O(1) key lookup paired with a doubly linked list for O(1) move-to-front and eviction
• Why not just one: a hashmap alone can't track recency order in O(1); a linked list alone can't locate a node in O(1) -- the combination is what makes both operations constant time

The trap most candidates fall into is updating recency inside get() but forgetting to do it on put() for an existing key, or forgetting to remove the evicted node from the map as well as the list. Mention the dummy head/tail sentinel nodes out loud -- they eliminate null-checks at the boundaries and are what separates clean code from a pile of edge cases.

public class LRUCache<K, V> {
  private final int capacity;
  private final Map<K, Node<K, V>> map = new HashMap<>();
  private final Node<K, V> head = new Node<>(null, null);
  private final Node<K, V> tail = new Node<>(null, null);

  public LRUCache(int capacity) {
    this.capacity = capacity;
    head.next = tail;
    tail.prev = head;
  }

  public V get(K key) {
    Node<K, V> node = map.get(key);
    if (node == null) return null;
    moveToFront(node);
    return node.value;
  }

  public void put(K key, V value) {
    if (map.containsKey(key)) {
      map.get(key).value = value;
      moveToFront(map.get(key));
      return;
    }
    if (map.size() == capacity) {
      Node<K, V> lru = tail.prev;
      remove(lru);
      map.remove(lru.key);
    }
    Node<K, V> node = new Node<>(key, value);
    map.put(key, node);
    addToFront(node);
  }
}

Practice this one: Design an LRU Cache on LLDCanvas - full brief, staged hints, and a live UML canvas.

3. Design an Elevator System

Frequency: High | Companies: Amazon, Uber, Flipkart. This question tests whether you can model a system that reacts to external events over time, not just a static data structure.

• Core entities: Elevator, ElevatorController, Request (internal floor button vs. external hall call), Door
• Key patterns: State (IDLE / MOVING_UP / MOVING_DOWN / DOOR_OPEN), Strategy (the scheduling algorithm), Observer (floor displays and call buttons)

Real elevators don't serve requests first-come-first-served -- they use the SCAN (or LOOK) algorithm: keep moving in one direction, picking up every request along the way, and only reverse once nothing is left ahead. Say this explicitly; it's the single fact that signals you've thought past 'moving between floors' into how dispatch actually works.

public interface ElevatorState {
  void handleRequest(ElevatorController controller, int floor);
}

public class MovingUpState implements ElevatorState {
  public void handleRequest(ElevatorController controller, int floor) {
    if (floor > controller.getCurrentFloor()) {
      controller.addStop(floor);
    } else {
      controller.queueForNextDirection(floor);
    }
  }
}

public class ElevatorController {
  private ElevatorState state = new IdleState();

  public void setState(ElevatorState state) {
    this.state = state;
  }
}

Practice this one: Design an Elevator System on LLDCanvas - full brief, staged hints, and a live UML canvas.

4. Design a Vending Machine

Frequency: High | Companies: Google, Microsoft, Amazon. A compact, self-contained state machine that's ideal for testing whether you reach for the State pattern instead of a tangle of boolean flags.

• Core entities: VendingMachine, Inventory, Product, Coin/Payment, VendingState
• Key patterns: State (Idle / HasMoney / Dispense / ReturnChange), Singleton (one machine instance), Factory (building the right product or coin objects)

Each state should implement a common VendingState interface with methods like insertCoin(), selectProduct(), and dispense(), and each concrete state decides which of those calls are even legal from that point. This is a textbook State pattern, and interviewers use it specifically to check whether you default to a five-branch if/else chain or to real polymorphism.

public interface VendingState {
  void insertCoin(VendingMachine machine, Coin coin);
  void selectProduct(VendingMachine machine, String code);
  void dispense(VendingMachine machine);
}

public class IdleState implements VendingState {
  public void insertCoin(VendingMachine machine, Coin coin) {
    machine.addBalance(coin.getValue());
    machine.setState(new HasMoneyState());
  }

  public void selectProduct(VendingMachine machine, String code) {
    throw new IllegalStateException("Insert coin first");
  }

  public void dispense(VendingMachine machine) {
    throw new IllegalStateException("Insert coin first");
  }
}

Practice this one: Design a Vending Machine on LLDCanvas - full brief, staged hints, and a live UML canvas.

Practice these live: All 25 problems in this list are available on LLDCanvas with a problem brief, staged hints, and a UML canvas -- so you design before you code, the way a real interview works.

5. Design a Library Management System

Frequency: High | Companies: Amazon, Flipkart, and most product companies with an internal-tools flavor to their interview loop.

• Core entities: Library, Book (catalog metadata), BookItem (one physical copy), Member, Loan/Reservation
• Key patterns: Factory (member/account types), Strategy (fine calculation), Observer (notifying members when a reserved title becomes available)

The modeling decision that matters most here is separating Book from BookItem. Book is the catalog entry -- title, author, ISBN -- while BookItem is one physical, borrowable copy with its own barcode and status. Collapse these into a single class and you can't represent a popular title with five copies, three of which are checked out; keep them separate and reservations, fines, and availability all fall out naturally.

Practice this one: Design a Library Management System on LLDCanvas - full brief, staged hints, and a live UML canvas.

6. Design an ATM Machine

Frequency: High | Companies: Amazon, banks and fintechs, and most generalist product companies.

• Core entities: ATM, Card, Account, Transaction, CashDispenser
• Key patterns: State (card inserted -> PIN entry -> transaction selection -> dispensing), Chain of Responsibility (breaking a withdrawal amount into denominations), Command (encapsulating each transaction type)

Treat the ATM itself as a state machine first -- it's what stops your code from allowing a withdrawal before a PIN has been entered. Then treat cash dispensing as a Chain of Responsibility: a handler for 2000-rupee notes hands off the remainder to a handler for 500s, which hands off to 100s, so adding a new denomination never touches the withdrawal logic itself.

Practice this one: Design an ATM Machine on LLDCanvas - full brief, staged hints, and a live UML canvas.

7. Design a Chess Game

Frequency: Medium-high | Companies: Google, Amazon, and companies that want to test polymorphism specifically rather than system-design breadth.

• Core entities: Board, Piece (King, Queen, Rook, Bishop, Knight, Pawn), Player, Move
• Key patterns: Abstract Factory (piece creation per side), Strategy (each piece's movement rule), Command (moves, enabling undo/redo and move history)

Every Piece subclass should implement its own getValidMoves(Board board) -- that's the whole exercise. If you find yourself writing a big switch statement inside Board to figure out how a bishop moves, you've missed the point of the question; the polymorphism has to live on the piece, not on the board.

Practice this one: Design a Chess Game on LLDCanvas - full brief, staged hints, and a live UML canvas.

8. Design a Ride-Sharing System (Uber / Lyft)

Frequency: High, and rising | Companies: Uber, Ola, Amazon, and most companies in the mobility or logistics space.

• Core entities: Rider, Driver, Trip, Location, MatchingService, Fare
• Key patterns: Strategy (matching and pricing algorithms), Observer (live location updates to both parties), State (trip lifecycle), Factory (vehicle-tier specific trip objects)

The trip itself is a state machine -- REQUESTED -> MATCHED -> IN_PROGRESS -> COMPLETED/CANCELLED -- and interviewers expect you to enumerate those states unprompted. The harder part they're actually probing for is the matching strategy: can you describe, even at a high level, how you'd find the nearest available driver using a geospatial index like a grid or geohash, instead of scanning every driver in the city?

Practice this one: Design a Ride-Sharing Backend on LLDCanvas - full brief, staged hints, and a live UML canvas.

9. Design a Hotel Booking System

Frequency: Medium-high | Companies: Amazon, Flipkart, and travel-tech companies running Airbnb- or MakeMyTrip-style rounds.

• Core entities: Hotel, Room (by type/rate), Booking, Guest, Payment
• Key patterns: Factory (room-type creation), Strategy (dynamic pricing by season or demand), Command (booking actions for cancellation/modification)

This question is really a concurrency question wearing a modeling costume. The core requirement is guaranteeing that no two guests can book the same room for overlapping dates -- which means your availability check and your booking write must be atomic (a database transaction with proper locking, or an optimistic-concurrency version check), not two separate steps that can race each other.

Practice this one: Design a Hotel Booking System on LLDCanvas - full brief, staged hints, and a live UML canvas.

Shaky on when to reach for Strategy versus State versus Observer? The Design Patterns for LLD Interviews guide walks through exactly when each pattern earns its place in an interview answer.

02Questions 10-25: Quick Reference

The remaining questions appear less often individually, but you should still recognize the core pattern for each at a glance. Use this table as a final review pass the night before an interview.

03Conclusion

Twenty-five questions is a lot to hold in your head at once, but they collapse into a much smaller set of ideas once you notice the overlap: State machines show up in more than half of them, Strategy in nearly all, and Observer in most of the rest. Learn those three patterns well enough to recognize them instantly, and this stops looking like 25 separate problems and starts looking like the same handful of decisions applied to different domains.

If you only have time to prepare a handful of these before an interview, prioritize questions 1 through 4 -- they're asked most frequently, they cover the widest range of patterns, and interviewers routinely default to one of them when they don't have a specific system in mind. Everything from question 5 onward is a variation you'll recognize once the core four are second nature.

Next step: Work through the full LLD Interview Roadmap to turn this list into a structured, week-by-week study plan.