The 5-Step LLD Framework

Why You Need a Framework — Even More Than in HLD

Picture Raj at his SDE-3 onsite. The interviewer says, "design a movie booking system." Raj knows Strategy. He knows Factory. He's read about every GoF pattern twice. So he opens the whiteboard, draws a class called Movie, then a class called Theater, then a class called Booking — and freezes. The classes are right but the relationships are vague. He hasn't named the requirements. He hasn't decided whether Seat is a class or a field on Theater. He hasn't thought about race conditions on bookings. Twenty-five minutes in he's drawing arrows between boxes that he's not sure point in the right direction. The interviewer asks "what does book() actually do?" and Raj realises he hasn't decided who owns the seat-locking logic.

The problem isn't that Raj doesn't know patterns. The problem is he has no playbook for the order of operations. LLD interviews need structure even more than HLD ones, because LLD has more degrees of freedom — every entity could be a class or a field, every method could live on the producer or the consumer, every variation point could be a Strategy or a Factory or just a switch statement. Without an order, you'll thrash.

This page lays out the 5 steps, gives you the timebox for each, then shows them in action on a "design a parking lot" prompt. By the end you should be able to walk into any LLD interview and know exactly what you're going to do at minute 5, minute 15, minute 25, and minute 35.

The 5-Step Framework — A 45-Minute Timeline

Here's the playbook on one page. Five distinct phases, ordered the way a senior engineer would actually approach a new domain in a real design review. Each step has a hard timebox — the goal isn't to finish fast, it's to spend exactly the right amount on each phase so you reach the code with the interviewer still engaged.

Step 1 — Clarify Requirements

The single most undervalued step. Candidates who skip it always design the wrong thing. The interviewer's gentle "interesting, but what about X?" twenty minutes in lands like a wrecking ball, and there's no time to recover. Five minutes here saves twenty later.

Functional requirements — top 3 user actions

Phrase each as "a user should be able to..." Resist the urge to brainstorm 15 features. The interviewer doesn't have time to design 15 things in 45 minutes, and the loop is graded on depth, not breadth. Pick the 3 hardest, hardest-coupled features — they'll force out the most interesting design choices.

Non-functional requirements — quantify or skip

NFRs in LLD are smaller in scope than HLD ones — you don't need to estimate QPS — but you still need to commit to a few. The good list: concurrency model extensibility direction performance budget durability. Each one constrains a later design choice.

The "out of scope" line — the most underused move

Saying "I'm not designing X" is as valuable as saying "I'm designing Y". It tells the interviewer you've considered the trade-off and made a deliberate cut. "Payment gateway integration is out of scope — I'll use a PaymentProvider interface so production swaps in Stripe; the LLD focuses on the in-memory model" earns more credit than silently leaving payments unaddressed.

Step 2 — Identify Core Entities

List the data nouns the system manipulates. One sentence of responsibility per entity. No fields yet, no relationships, no methods — just names and what each one is responsible for. This step exists to establish vocabulary with the interviewer so when you say "Spot" or "Ticket" later, you both mean the same thing.

How to find the entities — circle the nouns

Read the requirements out loud. Every concrete noun that has its own state or its own lifecycle is an entity candidate. Adjectives and verbs are not entities — they become fields and methods. "Park a car in a spot" gives you Car, Spot (entities) and park() (method). "in" isn't an entity.

Six entities is the sweet spot for a parking lot. Less than four and you're hiding complexity in fat classes; more than nine and you're overdesigning. If you're tempted to add EntryGate, ExitGate, and DisplayBoard — pause. Those are interface concerns, not domain entities. Mention them in passing if asked, but don't pollute the diagram.

The three reasons this step earns its time

Step 3 — Class Diagram

Now the entities get fields, methods, and relationships. This is where most of the LLD score is decided. The interviewer is watching for two things: (a) does the class structure cleanly map to the domain you described in Step 2, and (b) do the relationships use the right kind of arrow — inheritance vs composition vs aggregation vs association?

The four relationships you must know cold

Mermaid example — the parking lot's class spine

How to narrate this aloud

The diagram alone earns nothing if the interviewer can't follow why each arrow is the kind of arrow it is. As you draw, say: "ParkingLot composes Floor — floors don't exist outside their lot. Floor composes Spot for the same reason. Spot is abstract because Bike, Car, and Truck spots have different size constraints — that's inheritance because they truly substitute. PricingStrategy is an interface that ParkingLot holds by reference (association) because pricing rules change every quarter and I want a new rule to be a new file."

Step 4 — Apply Patterns & Draw the Sequence

Now you find the variation points in the design — the places where requirements are most likely to change next quarter — and you apply the GoF pattern that absorbs that change cleanly. Then you draw the happy-path sequence so the interviewer can see the runtime, not just the static topology.

How to spot a variation point

Ask one question per noun in the diagram: "if I had to add a new variant of this next month, would the existing code change?" If yes, that's a variation point. The pattern toolbox is in Part 3; the cheat-sheet for picking the right one is below.

Sequence diagram — show one user action end-to-end

Pick the most important user action — usually the one from your top functional requirement — and draw the sequence of method calls between objects. A sequence diagram is worth ten paragraphs of explanation; the interviewer can see the runtime.

Notice two things in the sequence. One: the alt block makes the race condition visible. Two drivers hitting the same spot is a real risk and showing the CAS retry path scores points without anyone asking. Two: every participant is a real class from your Step 3 diagram. If a sequence message has no class to send it to, you're missing an entity.

Step 5 — Write the Java

Twelve minutes is not a lot. The temptation is to start with the most exciting class and write it in detail. The right move is the opposite — write the boring scaffolding first (enums, interfaces) so the meat in the middle has something to lean on, and end with one main() that exercises the happy path. If the interviewer can read your main() top-to-bottom and see the design come alive, you win the loop.

The order of operations

A skeleton in 60 lines (the kind that fits on a whiteboard)

enum VehicleSize { BIKE, CAR, TRUCK }

interface PricingStrategy {
  double calculate(Duration stay, VehicleSize size);
}

interface SpotAllocator {
  Optional<Spot> findAndOccupy(VehicleSize size);
}

abstract class Spot {
  protected final String id;
  protected final VehicleSize size;
  protected final AtomicReference<Vehicle> occupant = new AtomicReference<>();

  Spot(String id, VehicleSize size) { this.id = id; this.size = size; }

  boolean tryOccupy(Vehicle v) {
    return v.size().ordinal() <= size.ordinal()
        && occupant.compareAndSet(null, v);   // race-safe
  }
  void vacate() { occupant.set(null); }
}

class CarSpot   extends Spot { CarSpot(String id)   { super(id, VehicleSize.CAR); } }
class TruckSpot extends Spot { TruckSpot(String id) { super(id, VehicleSize.TRUCK); } }

record Vehicle(String licensePlate, VehicleSize size) {}
record Ticket(String id, Spot spot, Instant entry) {}
record Bill(Ticket ticket, double amount, Duration stay) {}

class ParkingLot {
  private final SpotAllocator allocator;
  private final PricingStrategy pricing;
  private final Map<String, Ticket> openTickets = new ConcurrentHashMap<>();

  ParkingLot(SpotAllocator allocator, PricingStrategy pricing) {
    this.allocator = allocator;
    this.pricing   = pricing;
  }

  Ticket park(Vehicle v) {
    Spot spot = allocator.findAndOccupy(v.size())
                .orElseThrow(() -> new LotFullException(v.size()));
    Ticket t = new Ticket(UUID.randomUUID().toString(), spot, Instant.now());
    openTickets.put(t.id(), t);
    return t;
  }

  Bill exit(String ticketId) {
    Ticket t = openTickets.remove(ticketId);
    if (t == null) throw new UnknownTicketException();
    Duration stay = Duration.between(t.entry(), Instant.now());
    t.spot().vacate();
    return new Bill(t, pricing.calculate(stay, t.spot().size), stay);
  }
}

public class Demo {
  public static void main(String[] a) throws Exception {
    SpotAllocator  alloc   = new SimpleAllocator(List.of(new CarSpot("S-1")));
    PricingStrategy pricing = new HourlyPricing(40.0);
    ParkingLot     lot     = new ParkingLot(alloc, pricing);

    Ticket t = lot.park(new Vehicle("KA-01-AB-1234", VehicleSize.CAR));
    Thread.sleep(3000);
    Bill b = lot.exit(t.id());
    System.out.println("Pay: ₹" + b.amount());
  }
}

Specifying Implementations — Where Senior Beats Junior

Of all the things that separate a junior-level LLD answer from a senior one, the biggest is specificity. Junior candidates name a class; senior candidates name the class, the data structure inside it, the concurrency primitive, the failure mode, and the extension point. Same five seconds, ten times the signal.

Walkthrough — "Design a Parking Lot" in 45 Minutes

Below is a minute-by-minute script of an idealised candidate (call her Priya) running the framework on the parking-lot prompt. Read it as the tempo and tone you should aim for — concise, structured, narrating the framework out loud as she builds.

The same script, with timing annotations

Mapping This Site's LLDs to the Framework

Each existing LLD on this site emphasises different framework steps and showcases different patterns. When you're practising, pick a page based on the step you want to drill.