HLD vs LLD - Learning Module

Loading content...

0/273

Low-Level Design: Classes, Interfaces, and Methods

From Architecture to Implementation

If High-Level Design is the architect's blueprint, Low-Level Design (LLD) is the structural engineer's detailed plans—the precise specifications that construction workers follow to build the actual structure.

Where HLD answers "What components does this system need?", LLD answers "How do we build each component?" It's the bridge between architectural vision and executable code, the layer where abstract boxes in diagrams become concrete classes, interfaces, and methods.

Low-Level Design is where software engineering craftsmanship truly shines. A well-designed class hierarchy, a clean interface, a method with exactly the right signature—these are the marks of an engineer who understands not just what to build, but how to build it elegantly.

What You Will Learn

By the end of this page, you will understand the scope and importance of Low-Level Design, how to think in terms of classes, interfaces, and methods, and the key principles that guide implementation-level design decisions. You'll see how LLD brings architectural decisions to life.

What Is Low-Level Design?

Low-Level Design (LLD) is the process of designing the internal structure of individual components. While HLD defines what components exist and how they interact, LLD defines how each component works internally.

LLD is concerned with:

Classes and Objects — The building blocks of object-oriented systems
Interfaces and Contracts — The promises components make to each other
Methods and Functions — The operations that perform the actual work
Data Structures — How data is organized within a component
Algorithms — The step-by-step procedures that solve specific problems
Design Patterns — Proven solutions to common design challenges

The Scope of LLD

LLD operates at the level of a single service or component. If HLD produced a box labeled "User Service," LLD designs everything inside that box:

What classes does the User Service contain?
What interfaces do these classes implement?
How do classes collaborate to fulfill the service's responsibilities?
What methods does each class expose?
How is data validated, transformed, and persisted?
What design patterns solve the specific challenges this service faces?

The Street-Level View

If HLD is the 30,000-foot view of a city, LLD is walking the streets. You see individual buildings, their entrances, their internal layouts. You understand how people move through spaces, where they wait, where they go. This ground-level perspective is essential for actually building something that works.

Classes: The Building Blocks of LLD

In object-oriented design, classes are the fundamental units of organization. A class defines:

State — The data the class holds (attributes, fields)
Behavior — The operations the class can perform (methods)
Identity — Each instance (object) is distinct, even with the same state

Good class design is about finding the right abstractions—grouping related state and behavior in ways that make the system understandable, maintainable, and extensible.

Principles of Good Class Design

Several time-tested principles guide effective class design:

SOLID Principles

•Single Responsibility Principle (SRP) — A class should have only one reason to change. If a class handles user authentication AND email sending, it has two reasons to change and should be split.
•Open/Closed Principle (OCP) — Classes should be open for extension but closed for modification. Add new behavior by extending, not by changing existing code.
•Liskov Substitution Principle (LSP) — Subclasses must be substitutable for their base classes. If code works with a base class, it should work with any subclass without surprises.
•Interface Segregation Principle (ISP) — Clients shouldn't depend on interfaces they don't use. Split large interfaces into smaller, focused ones.
•Dependency Inversion Principle (DIP) — High-level modules shouldn't depend on low-level modules. Both should depend on abstractions (interfaces).

SOLID Is a Guide, Not a Religion

SOLID principles are guidelines, not laws. Blindly applying them can lead to over-engineering—dozens of tiny classes and interfaces that are harder to understand than a single, slightly-larger class. Use judgment. The goal is maintainability, not adherence to dogma.

Class Relationships

Classes don't exist in isolation. Understanding how classes relate to each other is crucial:

Association — One class uses another ("User has a List of Orders")
Aggregation — A "has-a" relationship where the contained object can exist independently ("Department has Employees")
Composition — A stronger "has-a" where the contained object can't exist independently ("House has Rooms")
Inheritance — An "is-a" relationship ("Dog is an Animal")
Dependency — One class uses another temporarily (passed as a parameter, created locally)
Realization — A class implements an interface

Interfaces: Contracts and Abstractions

Interfaces define contracts—promises about what a class can do without specifying how it does it. They are the cornerstone of abstraction in LLD.

An interface says: "I guarantee these methods exist with these signatures." It doesn't say anything about implementation. This separation of what from how is powerful:

Multiple implementations — Different classes can fulfill the same interface differently (e.g., FileLogger, DatabaseLogger, CloudLogger all implement Logger)
Testability — Tests can use mock implementations that satisfy the interface
Flexibility — Swap implementations without changing calling code
Decoupling — Code depends on abstractions, not concrete classes

PaymentProcessor Interface Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// Interface defines the contract
interface PaymentProcessor {
  processPayment(amount: number, currency: string): PaymentResult;
  refund(transactionId: string): RefundResult;
  getTransactionStatus(transactionId: string): TransactionStatus;
}
 
// Stripe implementation
class StripePaymentProcessor implements PaymentProcessor {
  private stripe: StripeClient;
  
  constructor(apiKey: string) {
    this.stripe = new StripeClient(apiKey);
  }
  
  processPayment(amount: number, currency: string): PaymentResult {
    // Stripe-specific implementation
    const charge = this.stripe.charges.create({ amount, currency });
    return { success: true, transactionId: charge.id };
  }
  
  // ... other methods
}
 
// PayPal implementation
class PayPalPaymentProcessor implements PaymentProcessor {
  private paypal: PayPalClient;
  
  processPayment(amount: number, currency: string): PaymentResult {
    // PayPal-specific implementation
    const payment = this.paypal.createPayment({ amount, currency });
    return { success: true, transactionId: payment.id };
  }
  
  // ... other methods
}
 
// Calling code works with any implementation
function checkout(processor: PaymentProcessor, amount: number) {
  const result = processor.processPayment(amount, 'USD');
  if (result.success) {
    console.log(`Payment successful: ${result.transactionId}`);
  }
}

Interface Design Principles

Well-designed interfaces are:

Focused — Do one thing. An EmailSender sends emails; it doesn't also validate email addresses.
Stable — Change rarely. Changing an interface ripples through all implementations.
Complete — Contain all methods needed to use the abstraction, no more, no less.
Intention-Revealing — Names should express what they do, not how.
Implementation-Agnostic — No method should leak implementation details.

Interface Bloat

Avoid 'god interfaces' with dozens of methods. If an interface is hard to implement because it has too many methods, it's violating the Interface Segregation Principle. Split it. If an interface has no implementations, question whether it's needed at all.

Methods: The Executable Units

Methods (or functions) are where computation actually happens. They're the verbs of your system—the actions that transform state, make decisions, and produce results.

Method design is a micro-level craft, but its importance is immense. A system is only as good as its methods.

Method Signature Design

A method signature communicates intent through:

Name — What does it do? Use verbs (calculateTotal, sendEmail, validateUser)
Parameters — What does it need? Minimize count; prefer objects for multiple related values
Return Type — What does it produce? Be specific; avoid returning null when you can return Optional or an empty collection
Exceptions — What can go wrong? Declare checked exceptions; document runtime exceptions

Method Naming Conventions by Purpose
Purpose	Naming Pattern	Example	Notes
Query (read)	get, find, is, has, can*	getUser(), findByEmail(), isActive()	Should have no side effects
Command (write)	create, update, delete, set, add*	createOrder(), updateProfile(), deleteAccount()	May modify state
Calculation	calculate, compute, determine*	calculateTotal(), computeHash()	Pure function, no side effects
Conversion	to, as, from*	toString(), asDTO(), fromEntity()	Transforms one type to another
Validation	validate, check, verify*	validateInput(), checkPermissions()	Returns boolean or throws
Factory	create, build, make, of	List.of(), StringBuilder.build()	Creates and returns new objects

Principles of Good Method Design

•Single Abstraction Level — Each method should work at one level of abstraction. Don't mix high-level policy (processOrder) with low-level details (formatStreetAddress).
•Command-Query Separation — Methods either change state (commands) or return values (queries), but not both. getNextItem() that also removes it is confusing.
•Avoid Side Effects — If a method is named validate, it shouldn't also modify the input. Side effects should be obvious from the name.
•Small and Focused — Methods should do one thing. If you need 'and' to describe it ('validates and saves'), split it.
•Limit Parameters — More than 3-4 parameters suggest the method is doing too much or parameters should be grouped into an object.

The 'Newspaper' Test

Good code reads like a newspaper: important high-level concepts at the top (method names that tell you what happens), details as you go deeper (implementation). A developer should understand what a method does from its signature before reading the body.

Design Patterns: Proven Solutions

Design patterns are reusable solutions to common problems in software design. They're not code you copy-paste—they're templates that guide your design decisions.

In LLD, design patterns help you:

Communicate design intent to other developers ('we use Strategy pattern here')
Avoid reinventing solutions to solved problems
Structure code for flexibility and maintainability
Recognize when a problem has a known solution

Essential Design Patterns for LLD
Pattern	Category	Purpose	When to Use
Factory	Creational	Create objects without specifying exact class	When creation logic is complex or varies
Builder	Creational	Construct complex objects step by step	Objects with many optional parameters
Singleton	Creational	Ensure only one instance exists	Shared resources; use sparingly
Strategy	Behavioral	Define family of interchangeable algorithms	When behavior varies based on context
Observer	Behavioral	Notify multiple objects of state changes	Event systems, reactive updates
Decorator	Structural	Add behavior to objects dynamically	Adding features without subclassing
Adapter	Structural	Convert interface to expected interface	Integrating with external libraries
Repository	Architectural	Mediate between domain and data mapping	Clean separation of persistence logic

Pattern Overuse

A common junior developer mistake is seeing patterns everywhere and applying them unnecessarily. Patterns add complexity. Use them when you genuinely need the flexibility they provide, not because you learned about them and want to practice. Simplicity beats cleverness.

Patterns as Vocabulary

Beyond their direct utility, patterns provide a shared vocabulary. When you say 'This class is a Decorator over the base service,' experienced developers immediately understand the structure without seeing the code. This communication efficiency is invaluable in team settings.

Data Structures and Algorithms in LLD

LLD is where data structure and algorithm choices become concrete. While HLD might say 'we need a cache,' LLD decides what data structure backs that cache and how it handles eviction.

Choosing Data Structures

Every data structure has trade-offs:

Data Structure	Access	Search	Insert	Delete	When to Use
Array/List	O(1)	O(n)	O(n)	O(n)	Fixed-size, index access
Linked List	O(n)	O(n)	O(1)	O(1)	Frequent insert/delete
Hash Map	O(1)*	O(1)*	O(1)*	O(1)*	Key-value lookup
Tree Set	O(log n)	O(log n)	O(log n)	O(log n)	Sorted, range queries
Heap	O(1) top	O(n)	O(log n)	O(log n)	Priority access

*Average case, assuming good hash distribution

Algorithm Selection

Similarly, algorithm choice impacts performance:

Sorting: Do you need stability? How large is the data? In-memory or external?
Searching: Is the data sorted? How often do you search vs. update?
Graph algorithms: BFS for shortest path in unweighted graphs; Dijkstra for weighted; A* for heuristic-guided search
String matching: Naive for small strings; KMP or Boyer-Moore for large texts

Big-O Is Not Everything

Asymptotic complexity matters, but constant factors matter too. An O(n) algorithm with huge constants can be slower than O(n log n) for practical input sizes. Also consider cache locality, memory usage, and parallelizability. Profile before optimizing.

LLD Artifacts and Diagrams

LLD produces specific artifacts that guide implementation:

Key LLD Artifacts

•Class Diagrams — Show classes, their attributes, methods, and relationships. The canonical LLD diagram.
•Sequence Diagrams — Show how objects interact over time for specific scenarios. Essential for complex flows.
•State Diagrams — Show state transitions for stateful objects. Useful for entities with lifecycles.
•Activity Diagrams — Show workflow and decision logic. Useful for complex business rules.
•API Specifications — Detailed interface definitions (OpenAPI, gRPC schemas). The contract between components.
•Database Schemas — Table definitions, relationships, indexes. The physical data model.

From Diagram to Code

Unlike HLD diagrams that remain abstract, LLD diagrams should be directly translatable to code:

Each class in a class diagram becomes a class/file in code
Each method in the diagram becomes a method in the class
Relationships become fields or method parameters
The diagram should be accurate enough that a developer could implement from it

This tight coupling between diagram and code is what makes LLD 'low-level'—it's close to the final implementation.

Summary: The Craft of Low-Level Design

We've explored the fundamentals of Low-Level Design. Let's consolidate the key takeaways:

Key Takeaways

•LLD designs component internals — While HLD defines components, LLD designs what's inside them—classes, interfaces, methods.
•Classes encapsulate state and behavior — Good classes have single responsibilities and clear boundaries.
•Interfaces define contracts — They separate what from how, enabling multiple implementations and testability.
•Methods are the executable units — Well-designed methods are focused, intention-revealing, and operate at a single abstraction level.
•Design patterns provide proven solutions — Use them as vocabulary and templates, not as ends in themselves.
•Data structure and algorithm choices matter — LLD is where abstract 'cache' becomes concrete 'LRU cache backed by HashMap + doubly-linked list.'

What's Next:

Now that we understand both HLD and LLD independently, we'll explore when to focus on each. In the next page, we'll discuss the contexts, scenarios, and criteria that determine whether you should be thinking architecturally or diving into implementation details.

Page Complete

You now understand Low-Level Design—the world of classes, interfaces, and methods where architectural decisions become executable code. Next, we'll explore when to focus on HLD versus LLD and how to switch between these complementary perspectives.