How to approach a low-level design question (identify actors, extract entities, assign responsibilities, apply patterns)

• Clarify requirements – pin down functional needs, constraints, and explicit out-of-scope items before designing anything.
• Identify actors – find the people or external systems that interact with the system; they reveal the entry points and operations.
• Extract entities – scan the requirements for important nouns; these become your classes with their key attributes.
• Assign responsibilities – each class does one job (Single Responsibility Principle); no God class.
• Define relationships – composition, aggregation, or inheritance, plus interfaces where you expect variation.
• Apply patterns judiciously – use a pattern only when it solves a genuine problem, never for show.

What is a low-level design question?

A low-level design (LLD) question asks you to produce the class-level design of a bounded system: the entities, their fields and methods, the relationships between them, the interfaces, and the key patterns. The goal is a cohesive, extensible object model, not a premature framework.

In an interview, LLD questions are deliberately vague. The interviewer wants to see whether you ask clarifying questions, how you discover entities, and whether you apply patterns appropriately or force them.

How do you clarify requirements and scope?

The first step is to ask scoping questions. For a parking lot you would ask: how many levels, what vehicle types, is payment included, is it single-threaded or concurrent. Writing down scope prevents you from designing the wrong thing.

package com.bank.lld;

/**
 * Requirements captured for the Safe-Deposit Locker system
 * at National Bank of India.
 *
 * Functional:
 * - Rajesh (customer) can reserve a locker by size.
 * - Staff can check in / check out a customer.
 * - Payment is charged by duration.
 *
 * Constraints:
 * - Three locker sizes: SMALL, MEDIUM, LARGE.
 * - Maximum one active booking per customer.
 * - Concurrent access: multiple staff at multiple branches.
 *
 * Out of scope:
 * - Online booking portal (only in-branch).
 * - Insurance on locker contents.
 */
public class LockerSystemRequirements {
    // This class documents the scoping conversation.
}

How do you identify actors?

Actors are the people or external systems that interact with the system. For the locker system, they are the Customer, the Bank Staff, and the Audit System. Actors reveal the entry points and the operations the system must expose, which later become your public methods.

Actors:
  Customer (Rajesh, Priya)  → reserve locker, release locker
  Bank Staff                → check in, check out, view occupancy
  Audit System              → generate usage reports

How do you extract core entities?

Read the requirements and underline the important nouns. These become your classes. For the locker system: Locker, LockerVault, Customer, Booking, Payment.

package com.bank.model;

import java.math.BigDecimal;

public class Locker {
    private final String lockerId;
    private final LockerSize size;
    private boolean occupied;

    public Locker(String lockerId, LockerSize size) {
        this.lockerId = lockerId;
        this.size = size;
        this.occupied = false;
    }

    public boolean isOccupied() { return occupied; }

    public void occupy() {
        if (occupied) throw new IllegalStateException(
                "Locker " + lockerId + " is already occupied");
        this.occupied = true;
    }

    public void release() {
        if (!occupied) throw new IllegalStateException(
                "Locker " + lockerId + " is already free");
        this.occupied = false;
    }

    public String getLockerId() { return lockerId; }
    public LockerSize getSize() { return size; }
}

package com.bank.model;

public enum LockerSize {
    SMALL, MEDIUM, LARGE
}

Each entity gets its key attributes (fields) and its own state transitions. The Locker decides how it becomes occupied; the orchestrator does not reach in and flip a flag.

How do you assign single responsibilities?

Each class should do one job, following the Single Responsibility Principle.

• Locker tracks its own state (size, occupied).
• LockerVault manages a collection of lockers and finds a free one.
• Booking links a customer to a locker for a period.
• BookingService orchestrates the reservation flow.
• PricingStrategy computes the fee.

Resist the temptation to create a God class that manages lockers, computes prices, and handles bookings. Split responsibilities so each class has one clear reason to change.

package com.bank.model;

import java.util.List;
import java.util.Optional;

public class LockerVault {
    private final String vaultId;
    private final List<Locker> lockers;

    public LockerVault(String vaultId, List<Locker> lockers) {
        this.vaultId = vaultId;
        this.lockers = lockers;
    }

    public Optional<Locker> findFreeLocker(LockerSize size) {
        return lockers.stream()
                .filter(l -> l.getSize() == size && !l.isOccupied())
                .findFirst();
    }
}

How do you define relationships and interfaces?

Decide how entities relate:

• Composition (owns-and-dies-together): a LockerVault owns its Locker objects. If the vault is removed, the lockers go with it.
• Aggregation (has-but-independent): a Booking references a Customer, but the customer exists independently.
• Inheritance (genuine is-a): use only when the relationship is truly is-a, such as SavingsAccount is-a Account.
• Interfaces: introduce where you expect variation, such as a PricingStrategy for different fee tiers.

package com.bank.service;

import java.math.BigDecimal;

public interface PricingStrategy {
    BigDecimal computeFee(long hoursUsed);
}

package com.bank.service;

import java.math.BigDecimal;

public class HourlyPricingStrategy implements PricingStrategy {
    private final BigDecimal hourlyRate;

    public HourlyPricingStrategy(BigDecimal hourlyRate) {
        this.hourlyRate = hourlyRate;
    }

    @Override
    public BigDecimal computeFee(long hoursUsed) {
        return hourlyRate.multiply(BigDecimal.valueOf(hoursUsed));
    }
}

How do you apply design patterns appropriately?

Apply patterns only where they solve a genuine problem. This is the maturity signal interviewers look for.

• Strategy for pricing that genuinely varies by tier.
• Factory if object creation is complex and centralised.
• State for an entity with a real lifecycle (booking states).
• Observer if several things must react to an event.

Do not force patterns. Adding a pattern that solves no real problem is over-engineering and a red flag in an interview.

package com.bank.service;

import com.bank.model.*;
import java.math.BigDecimal;
import java.time.LocalDateTime;

public class BookingService {
    private final LockerVault vault;
    private final PricingStrategy pricing;

    public BookingService(LockerVault vault, PricingStrategy pricing) {
        this.vault = vault;
        this.pricing = pricing;
    }

    public Booking reserve(Customer customer, LockerSize size) {
        Locker locker = vault.findFreeLocker(size)
                .orElseThrow(() -> new IllegalStateException(
                        "No free " + size + " locker available"));
        locker.occupy();
        return new Booking(customer, locker, LocalDateTime.now());
    }

    public BigDecimal release(Booking booking) {
        booking.getLocker().release();
        long hours = java.time.Duration.between(
                booking.getStartTime(), LocalDateTime.now()).toHours();
        return pricing.computeFee(Math.max(1, hours));
    }
}

How do you verify the design?

Always trace a concrete scenario end to end. This exposes missing methods or awkward relationships before the interviewer finds them.

Scenario: Rajesh reserves a MEDIUM locker

1. BookingService.reserve(rajesh, MEDIUM)
2. LockerVault.findFreeLocker(MEDIUM) → Locker L-042
3. Locker L-042.occupy()
4. Create Booking(rajesh, L-042, now)
5. Return Booking to caller

Scenario: Rajesh releases the locker after 3 hours

1. BookingService.release(booking)
2. Locker L-042.release()
3. PricingStrategy.computeFee(3) → 150.00
4. Return fee to caller

What about concurrency?

If the problem implies concurrent access, raise it explicitly. Assigning a locker in a busy branch needs synchronisation or atomic operations so two staff members do not assign the same locker to different customers.

// Thread-safe locker assignment
public synchronized Optional<Locker> findAndOccupy(LockerSize size) {
    Optional<Locker> locker = findFreeLocker(size);
    locker.ifPresent(Locker::occupy);
    return locker;
}

What should a senior engineer know?

• Let entities own their state transitions. The Locker should decide how it becomes occupied, not have the orchestrator reach in and flip a flag.
• Design for the follow-up. Interviewers will ask "how would you add electric-vehicle charging spots?" or "how would you add a new locker size?" A good model answers that by adding a subtype or a new strategy, not by rewriting existing classes (Open/Closed Principle).
• Composition over inheritance. Default to composition. Use inheritance only for genuine is-a relationships.
• Diagram before code. In an interview, sketch the class diagram with relationships before writing any code. It communicates the design faster and is easier to revise.

What are common interview follow-up questions?

• How would you extend this design for a new locker size?
• Where would you use the Observer pattern in this system?
• How would you handle concurrent locker assignment?
• How would you add a cancellation policy?
• Draw the class diagram with relationships.