Bird
Raised Fist0

How to Approach Any LLD Problem in 45 Minutes - Step-by-Step Framework

LLDmediumInterview freq: high
Choose your preparation mode4 modes available
🏗️
How to Approach Any LLD Problem in 45 Minutes - Step-by-Step Framework
A structured 40-minute LLD interview walkthrough focusing on requirements, entities, relationships, concurrency, and code.
mediumOOP Foundations for InterviewsFreq: high
Prerequisites:OOP Fundamentals
⚙️
Functional Requirements
  • Ability to gather and clarify requirements including concurrency and edge cases
  • Identify and define entities with attributes and behaviors
  • Establish clear relationships with lifecycle ownership
  • Apply Java-specific concurrency controls to prevent race conditions
  • Produce a clean, extensible code skeleton with full method signatures
👤
Use Cases
  • Candidate clarifies problem requirements with interviewer
  • Candidate identifies key entities and their responsibilities
  • Candidate defines relationships and applies design patterns
  • Candidate addresses concurrency issues with Java mechanisms
  • Candidate writes code skeleton demonstrating core design
🧑‍💻
Actors
  • Interviewer
  • Candidate
  • System Under Design
❓
Clarifying Questions to Ask
  • How many concurrent threads or gates will interact with the system?
  • Are there any pricing or cost constraints affecting design?
  • What are the edge cases for input or system state?
  • Is the system expected to handle failures or retries?
  • What is the expected lifecycle of entities (creation, deletion)?
Out of Scope
✗ Detailed UI design
✗ Database schema design
✗ Deployment and scaling strategies
⚡
QPS Calculation
write qps1000
read qps5000
peak qps7000
🖥️
Server Estimate
10
Estimates based on typical interview system scale for LLD problems.
🔢
Enumerations
enum DesignPhase
REQUIREMENTS | ENTITIES | RELATIONSHIPS | CONCURRENCY | CODING
Enum prevents typo bugs and enables exhaustive switch statements for each design phase in the framework.
enum ConcurrencyMechanism
SYNCHRONIZED | VOLATILE | ATOMIC | NONE
Enumerates Java concurrency mechanisms to explicitly choose and document concurrency control strategies.
📦
Requirement
3 fields
String descriptionboolean isFunctionalboolean isOutOfScope
Capture and classify individual requirements, distinguishing functional from out-of-scope.
public String getDescription()Returns the textual description of the requirement.
public boolean isFunctionalRequirement()Indicates if the requirement is functional.
📦
Entity
3 fields
String nameList<String> attributesList<String> responsibilities
Define domain objects with state and behavior relevant to the problem.
public synchronized void addAttribute(String attribute)Adds an attribute to the entity in a thread-safe manner.
public synchronized void addResponsibility(String responsibility)Adds a responsibility to the entity ensuring thread safety.
📦
Relationship
5 fields
Entity fromEntity toString typeString cardinalityString lifecycle
Represent and manage relationships between entities with lifecycle ownership.
public String getRelationshipType()Returns the type of relationship (composition, aggregation, etc.).
public boolean isLifecycleOwned()Indicates if the 'from' entity owns the lifecycle of the 'to' entity.
📦
ConcurrencyScenario
4 fields
String scenarioDescriptionString problemDescriptionString solutionDescriptionList<String> solutionCode
Describe concurrency issues and their Java-specific solutions with code examples.
public List<String> getSolutionCode()Returns the Java code lines demonstrating the concurrency solution.
📦
CodeSkeleton
3 fields
List<String> codeLinesString classNameString purpose
Provide a minimal working Java code skeleton illustrating design decisions.
public List<String> getCodeLines()Returns the Java code lines for the skeleton.
🔗
Relationships
Requirement──►Entity[1..*]
associationindependent
Entity◇──►Relationship[1..*]
aggregationindependent
Relationship──►Entity[1]
associationindependent
CodeSkeleton──►Entity[1..*]
associationindependent
🗄️
Requirements
PK: requirement_id
🗄️
Entities
PK: entity_id
🔌
GET /requirements
Request
"None"
Response
"List of requirements with details"
Fetch all requirements for the current design problem.
🔌
POST /entities
Request
"Entity details JSON"
Response
"Created entity confirmation"
Add a new entity with attributes and responsibilities.
🔌
PUT /relationships
Request
"Relationship details JSON"
Response
"Updated relationship confirmation"
Define or update relationships between entities.

Practice

(1/5)
1. In the hotel system, should Vehicle be designed as an abstract class or an interface, considering that different vehicle types have state like license plate and behavior like parking? Why?
easy
A. Interface, because it allows multiple inheritance and all vehicles share behavior only.
B. Abstract class, because vehicles share common state and behavior that can be reused.
C. Interface, because state should be stored externally to keep Vehicle stateless.
D. Abstract class, because interfaces cannot define any methods with implementation.

Solution

  1. Step 1: Analyze Vehicle's state and behavior

    Vehicle has common state (license plate) and behavior (park, unpark) shared by all types.
  2. Step 2: Abstract class vs interface for state and behavior

    Abstract classes can hold state and provide default behavior; interfaces cannot hold instance state (Java 8+ default methods don't hold state). Thus, abstract class fits better.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Shared state + behavior -> abstract class [check]
Hint: Stateful base class -> abstract class, not interface [check]
Common Mistakes:
2. In the Food Ordering System, the KitchenQueue class has a parkOrder() method that checks if a slot is available before assigning an order. Without synchronization on parkOrder(), which exact thread interleaving causes double-booking of the same slot?
medium
A. Thread 1 and Thread 2 both call parkOrder() simultaneously and the JVM throws an exception.
B. Thread 1 checks slot availability -> true, context switch before assignment; Thread 2 checks availability -> true, both assign same slot.
C. Thread 1 assigns slot, then Thread 2 waits for Thread 1 to finish before assigning next slot.
D. Thread 1 and Thread 2 both wait on a lock, causing deadlock and no assignment.

Solution

  1. Step 1: Identify the check-then-act race condition

    Without synchronization, Thread 1 reads slot as available but is preempted before assignment; Thread 2 also reads available and proceeds.
  2. Step 2: Both threads assign the same slot leading to double-booking

    Because the availability check and assignment are not atomic, both threads assign the same slot concurrently.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Check-then-act gap without sync -> double assignment [check]
Hint: Check availability -> context switch -> both assign same slot [check]
Common Mistakes:
3. In a plugin loader, the loadPlugin() method checks if a plugin is already loaded before loading it. Without synchronizing this method, what exact thread interleaving causes the same plugin to be loaded twice?
medium
A. Thread 1 checks isLoaded() -> false, context switch; Thread 2 checks isLoaded() -> false; both proceed to load the plugin.
B. Thread 1 and Thread 2 both wait on a lock, causing deadlock.
C. Thread 1 loads plugin, but Thread 2 never sees the updated loaded state due to caching.
D. Thread 1 and Thread 2 both call loadPlugin() simultaneously and both throw exceptions.

Solution

  1. Step 1: Trace the check-then-act sequence without synchronization

    Thread 1 calls isLoaded() and sees false, then context switches before loading.
  2. Step 2: Thread 2 also calls isLoaded() and sees false, both threads proceed to load plugin concurrently, causing duplicate loading.

  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Unsynchronized check-then-act allows double loading due to race [check]
Hint: Check-then-act without sync -> double load race condition [check]
Common Mistakes:
4. In the in-memory file system, the createFile() method checks if a filename is available and then adds the file to the directory without synchronization. Which exact thread interleaving causes two threads to create files with the same name (double creation)?
medium
A. Thread 1 checks filename availability -> true, context switch; Thread 2 checks availability -> true; both add file with same name.
B. Thread 1 and Thread 2 both call createFile() simultaneously and both fail due to race condition.
C. Thread 1 adds file, then Thread 2 checks availability and finds it unavailable, so no conflict occurs.
D. Thread 1 deletes a file while Thread 2 creates a file with the same name, causing inconsistency.

Solution

  1. Step 1: Trace the check-then-act sequence without synchronization

    Thread 1 calls isNameAvailable() -> true, but before adding the file, context switches to Thread 2.
  2. Step 2: Thread 2 also calls isNameAvailable() -> true and proceeds to add the file, then Thread 1 resumes and adds its file too.

    This causes double creation due to the race condition on the availability check and add operation.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Check-then-act gap without sync -> double creation [check]
Hint: Check availability -> context switch -> both add same file [check]
Common Mistakes:
5. You want to add a WeekendFeeStrategy to an ATM system using the State pattern for fee calculation. Which change respects the Open-Closed Principle (OCP)?
medium
A. Add a boolean isWeekend flag to the existing FeeStrategy interface and handle it internally
B. Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it where needed
C. Modify the existing FeeCalculator class to add weekend logic
D. Add weekend fee logic directly inside each State class handling transactions

Solution

  1. Step 1: Understand OCP requirements

    OCP requires extending behavior without modifying existing code.
  2. Step 2: Evaluate options

    Add a boolean isWeekend flag to the existing FeeStrategy interface and handle it internally adds a flag to interface and implements logic in existing classes, avoiding new classes but modifying interface (violates OCP). Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it where needed adds a new class implementing FeeStrategy, extending behavior without modifying existing code, respecting OCP.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    New class for new fee strategy -> OCP respected [check]
Hint: OCP: extend with new class, don't modify existing code [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard