LLD Basics
Fast recall
Quick revision
Core answer
Whether you can translate a requirements statement into a class diagram with appropriate relationships, access modifiers, and SOLID-compliant design.
Jumping into code without identifying entities and relationships, or violating the Open/Closed Principle by hard-coding implementations instead of coding to interfaces.
Apply design patterns naturally (Strategy, Factory, Observer) without over-engineering, and explain how dependency injection enables testability and extensibility.
Interview-ready guide
Interview answer
Low-Level Design, or LLD, defines the inside of a software component: its classes, interfaces, fields, methods, relationships, and important object interactions. High-level design may say that an application has an order service and a payment service; LLD defines objects such as Order, Payment, OrderService, and PaymentGateway, along with the contracts through which they collaborate.
LLD exists to turn requirements into an implementation blueprint that several developers can follow consistently. It records where state lives, which object owns each rule, which relationships are composition or inheritance, and where an abstraction is needed for change or testing. SOLID principles help keep those boundaries cohesive, while patterns such as Strategy or State are used only when the requirements contain the variation or lifecycle they solve. A useful LLD is concrete enough to guide code and tests, but simple enough that another developer can read the model and trace a use case through it.
LLD Basics
Direct Answer
Low-Level Design (LLD) is the process of defining the internal structure of a software system at the class and method level -- specifying classes, their fields, method signatures, relationships (inheritance, composition, dependency), and the design patterns that govern them. It exists because high-level design (HLD) says what the system should do but not how the code should be organized, and without LLD, developers would each interpret the architecture differently, producing inconsistent, hard-to-maintain code. An LLD interview tests whether you can translate a vague problem statement into a clean, extensible class design grounded in SOLID principles and standard patterns.
Code Example
// SRP + OCP: each payment method is a separate class.
// Adding a new method does not require modifying CheckoutService.
// Abstraction that clients depend on (DIP)
interface PaymentProcessor {
boolean process(double amount);
}
// Concrete implementations -- extend without modifying existing code (OCP)
class CreditCardProcessor implements PaymentProcessor {
@Override
public boolean process(double amount) {
System.out.println("Charging $" + amount + " to credit card");
return true;
}
}
class UpiProcessor implements PaymentProcessor {
@Override
public boolean process(double amount) {
System.out.println("Paying $" + amount + " via UPI");
return true;
}
}
// High-level module depends on abstraction, not concretions (DIP)
class CheckoutService {
private final PaymentProcessor processor;
// Dependency injection via constructor -- enables mocking in tests
public CheckoutService(PaymentProcessor processor) {
this.processor = processor;
}
public void checkout(double amount) {
if (!processor.process(amount)) {
throw new RuntimeException("Payment failed");
}
System.out.println("Checkout complete for $" + amount);
}
}
// Usage -- inject any PaymentProcessor without changing CheckoutService
class Demo {
public static void main(String[] args) {
CheckoutService service = new CheckoutService(new UpiProcessor());
service.checkout(49.99);
}
}
Common Mistakes & Pitfalls
Jumping into code without identifying entities and relationships, or violating the Open/Closed Principle by hard-coding implementations instead of coding to interfaces.
Check your understanding
Answer these without looking back at the article.
- What are the SOLID principles and how do you apply them in LLD?
- When would you choose composition over inheritance?
- What is the Strategy pattern and when should you apply it?
- How do you decide between an interface and an abstract class in Java?
- What is dependency injection and why does it improve testability?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.