High-Level Design vs Low-Level Design

HLD describes the complete system architecture. LLD describes the internal implementation of individual components.

Software systems can be designed at different levels of detail.

High-Level Design, or HLD, describes the system’s overall architecture.

Low-Level Design, or LLD, describes how individual components will be implemented internally.

In simple terms:

High-Level Design shows the major parts of the system and how they connect. Low-Level Design explains how each part works internally.

Both are important, but they solve different problems.

A Simple Analogy

Imagine designing a city.

The high-level plan shows:

Residential areas
Commercial areas
Roads
Hospitals
Schools
Railway stations
Connections between different locations

It does not describe the internal structure of every building.

The low-level plan for a hospital might show:

Individual rooms
Doors and corridors
Electrical wiring
Water systems
Emergency exits
Equipment placement

Software design works similarly.

HLD provides the overall map. LLD provides the detailed implementation plan.

What Is High-Level Design?

High-Level Design describes the major building blocks of a software system and the relationships between them.

It focuses on questions such as:

What are the main components?
How do clients communicate with the system?
Which services are required?
Where is data stored?
How do services communicate?
How will the system scale?
How will failures be handled?
Which external systems are involved?

A high-level design might look like this:

                              ┌───────────┐
                         ┌───►│   Cache   │
                         │    └───────────┘
                         │
┌────────┐    ┌──────────┴─┐    ┌────────────┐
│ Client │───►│ API Service│───►│  Database  │
└────────┘    └──────────┬─┘    └────────────┘
                         │
                         ▼
                   ┌───────────┐
                   │   Queue   │
                   └─────┬─────┘
                         ▼
                   ┌───────────┐
                   │  Workers  │
                   └───────────┘

The diagram shows the important components, but it does not explain the internal classes or functions inside the API service.

What Does HLD Cover?

High-Level Design commonly includes:

System components

Examples include:

Clients
Load balancers
API gateways
Application services
Databases
Caches
Message queues
Background workers
Search engines
Object storage
Content delivery networks

Communication

HLD explains how components communicate using methods such as:

HTTP
REST
gRPC
WebSockets
Events
Message queues

Data flow

It shows how information moves through the system.

For example:

A client submits an order.
The order service validates it.
The database stores it.
An event is added to a message queue.
A background worker sends a confirmation email.

Data storage

HLD may describe:

Which type of database is required
Which service owns which data
Whether caching is needed
How data is replicated
How data is partitioned

Scalability

It considers:

Expected traffic
Horizontal scaling
Load balancing
Caching
Database replication
Sharding
Asynchronous processing

Reliability

It may include:

Redundant servers
Failover
Retries
Circuit breakers
Backups
Multi-region deployment

Security boundaries

It may show:

Authentication services
Private and public networks
API gateways
Authorisation boundaries
Connections with external providers

Typical HLD Documents

A High-Level Design may contain:

Architecture diagrams
Component descriptions
Request-flow diagrams
API contracts
Database choices
Main data entities
Scaling strategy
Reliability strategy
Security overview
Technology decisions
Important trade-offs

HLD explains the major decisions without describing every implementation detail.

What Is Low-Level Design?

Low-Level Design describes the internal structure and behaviour of an individual component.

It focuses on questions such as:

Which classes are needed?
What responsibility does each class have?
Which methods should each class provide?
How do objects interact?
Which design patterns should be used?
How should errors be handled?
How should concurrency be managed?
How can the code remain extensible and testable?

For example, a notification service in an HLD diagram might become the following LLD:

NotificationService
    ├── EmailSender
    ├── SmsSender
    ├── PushNotificationSender
    ├── TemplateRenderer
    ├── PreferenceManager
    └── DeliveryRepository

The HLD simply says that a notification service exists.

The LLD explains how that service is structured internally.

What Does LLD Cover?

Low-Level Design commonly includes:

Classes and objects

It defines the main classes and the responsibilities of each class.

For example:

Order
Customer
Product
Payment
InventoryReservation

Interfaces

Interfaces define behaviours without tying the design to one implementation.

For example:

PaymentProcessor
    processPayment()
    refundPayment()

Different implementations could support different payment providers.

Methods

LLD defines the operations available inside a component.

For example:

OrderService.createOrder()
OrderService.cancelOrder()
OrderService.getOrder()

Object relationships

It explains whether objects use:

Association
Composition
Inheritance
Dependency
Aggregation

Data structures

LLD may select structures such as:

Lists
Maps
Queues
Trees
Heaps
Graphs

Algorithms

It may describe the detailed steps used to solve a specific problem.

Design patterns

Common patterns include:

Factory
Strategy
Observer
Adapter
Decorator
State
Repository

State transitions

Systems such as orders and payments often move through defined states.

For example:

CREATED → CONFIRMED → SHIPPED → DELIVERED
                   ↘ CANCELLED

LLD defines which transitions are allowed and how invalid transitions are prevented.

Error handling

It explains:

Which errors can occur
How errors are represented
Which errors can be retried
How failed operations are cleaned up

Concurrency

LLD may consider:

Multiple threads
Race conditions
Locks
Atomic operations
Shared state
Thread safety

Testability

It should make components easy to test independently through clear interfaces and limited dependencies.

HLD vs LLD

Area	High-Level Design	Low-Level Design
Main focus	Overall system architecture	Internal component implementation
Main question	What components do we need?	How will each component work?
Level of detail	Broad	Detailed
Scope	Complete system	One service, module or feature
Main building blocks	Services, databases and queues	Classes, methods and objects
Communication	Between systems and services	Between classes and functions
Data	Storage choices and main entities	Fields, structures and validation
Scalability	Major concern	Usually a secondary concern
Reliability	System-wide failure handling	Component-level error handling
Design patterns	Architectural patterns	Object-oriented design patterns
Diagrams	Architecture and data-flow diagrams	Class and sequence diagrams
Audience	Architects, engineers and stakeholders	Engineers implementing the component
Common interview type	System design interview	Object-oriented or machine-coding interview

A Complete Example

Consider a food-delivery platform.

High-Level Design

The HLD might identify:

Customer application
Restaurant application
Driver application
API gateway
User service
Restaurant service
Order service
Payment service
Delivery service
Notification service
Location service
Databases
Cache
Message queue

A simplified architecture could be:

Customer App
      │
      ▼
 API Gateway
      │
      ├──► Restaurant Service
      ├──► Order Service ───► Order Database
      ├──► Payment Service ─► Payment Provider
      └──► Delivery Service ─► Location Service
                  │
                  ▼
             Message Queue
                  │
                  ▼
          Notification Service

This design explains the overall system but does not explain how the order service is written internally.

Low-Level Design

The LLD for the order component might define:

Order
    id
    customerId
    restaurantId
    items
    total
    status

OrderService
    createOrder()
    confirmOrder()
    cancelOrder()
    updateOrderStatus()

OrderRepository
    save()
    findById()
    update()

PricingService
    calculateSubtotal()
    calculateTax()
    calculateDeliveryFee()

OrderState
    validateTransition()

The LLD may also define allowed order states:

PENDING
   │
   ▼
CONFIRMED
   │
   ▼
PREPARING
   │
   ▼
READY
   │
   ▼
DELIVERED

It would also explain how cancellations, invalid transitions and payment failures are handled.

How HLD and LLD Work Together

HLD and LLD are not competing approaches. They are two stages of the same design process.

Requirements
     │
     ▼
High-Level Design
     │
     ▼
System Components
     │
     ▼
Low-Level Design
     │
     ▼
Implementation

The typical process is:

Understand the requirements.
Design the overall architecture.
Divide the system into components.
Define the responsibility of each component.
Design important components internally.
Implement and test the design.

The high-level architecture creates boundaries. The low-level design fills in the details inside those boundaries.

Decisions That Connect HLD and LLD

Some decisions affect both levels.

For example, HLD may decide that order processing uses asynchronous events.

LLD must then explain:

How events are represented
How handlers are organised
How duplicate events are detected
How failures are retried
How invalid messages are handled

Similarly, HLD may decide that a cache is required. LLD may define:

The cache interface
Cache-key generation
Time-to-live rules
Invalidation logic
Fallback behaviour

When Should HLD Be Created?

HLD is useful when:

Designing a new system
Adding a major feature
Dividing a system into services
Planning for higher traffic
Replacing important infrastructure
Integrating with an external system
Improving reliability
Migrating from one architecture to another

HLD should answer the important architectural questions before detailed implementation begins.

When Should LLD Be Created?

LLD is useful when:

A component has complex business rules
Multiple implementations are possible
The code must be highly extensible
State transitions are complicated
Several developers will work on the same component
Concurrency must be controlled
A reusable framework or library is being created
Implementation details could create significant risks

Simple components may not require a formal LLD document, but their responsibilities should still be clear.

HLD in System Design Interviews

Most high-level system design interviews begin with a broad problem such as:

Design a video-streaming platform.
Design a messaging application.
Design a URL shortener.
Design a notification system.
Design an online marketplace.

The discussion normally covers:

Functional requirements
Non-functional requirements
Capacity estimates
APIs
Data model
Major components
Request flow
Scalability
Failure handling
Trade-offs

The candidate is usually expected to remain at the architecture level unless the interviewer requests a deeper discussion.

For example, the interviewer might ask:

How would the database be partitioned?
How would message ordering work?
How would duplicate payments be prevented?
How would a popular item be cached?
How would the system recover from a regional failure?

These are deeper HLD discussions, but they usually do not require designing every class.

LLD in Interviews

Low-level design interviews may ask for systems such as:

Design a parking lot.
Design a vending machine.
Design an elevator.
Design a notification framework.
Design a library-management system.
Design a payment state machine.

The discussion normally covers:

Main entities
Class responsibilities
Interfaces
Object relationships
Design patterns
State management
Error handling
Extensibility
Testability
Code or pseudocode

An LLD interview may eventually require working code. This is sometimes called a machine-coding interview.

How Deep Should a Design Go?

The correct level of detail depends on the question and available time.

During an HLD interview, avoid designing every class unless requested. It can consume time needed for scalability and reliability discussions.

During an LLD interview, avoid spending most of the time on distributed infrastructure unless it directly affects the component being designed.

A useful rule is:

Start broad, confirm the architecture, and then go deeper into the parts that contain the most risk or complexity.

Common Mistakes

HLD mistakes

Drawing components without explaining their purpose
Choosing technologies before understanding requirements
Ignoring data flow
Ignoring failure scenarios
Adding unnecessary microservices
Forgetting scalability and consistency
Spending too much time on implementation details

LLD mistakes

Creating classes without clear responsibilities
Using inheritance unnecessarily
Building one large class that does everything
Applying design patterns without a real need
Ignoring error handling
Ignoring invalid state transitions
Creating tightly coupled components
Making the design difficult to test or extend

Mistakes affecting both

Starting before clarifying the requirements
Trying to design everything at once
Ignoring trade-offs
Creating unnecessary complexity
Failing to explain assumptions
Treating the first design as the only possible solution

How to Explain the Difference in an Interview

A short answer:

High-Level Design defines the overall architecture of a system, including services, databases, communication and data flow. Low-Level Design defines the internal implementation of those components using classes, interfaces, methods, states and design patterns.

A stronger answer:

HLD answers what major components the system needs and how they interact to meet scalability, reliability and performance requirements. LLD answers how an individual component should be structured so that it is correct, maintainable, testable and extensible. HLD provides the system map, while LLD provides the implementation details.

Interview Questions

What is the difference between HLD and LLD?
What information should an HLD document contain?
What information should an LLD document contain?
Which diagrams are commonly used in each?
Should HLD always be completed before LLD?
How do HLD decisions affect implementation?
When should a design move from HLD to LLD?
How much detail should be included in a system design interview?
Is API design part of HLD or LLD?
Can database design appear in both HLD and LLD?
How is an LLD evaluated for extensibility?
What happens when HLD and LLD do not match?

Is API Design HLD or LLD?

It can appear in both.

At the HLD level, an API may be described as:

POST /orders
GET /orders/{id}

At the LLD level, the design may describe:

Request validation
Controller methods
Service interfaces
Error classes
Data transformations
Internal method calls

Is Database Design HLD or LLD?

It can also appear in both.

HLD may decide:

SQL or NoSQL
Database ownership
Replication strategy
Partitioning strategy
Main entities

LLD may define:

Exact fields
Constraints
Indexes
Relationships
Repository methods
Validation rules

The boundary is not always strict. The important difference is the level of detail.

Key Takeaways

HLD describes the complete system architecture.
LLD describes the internal implementation of individual components.
HLD uses services, databases, caches and queues.
LLD uses classes, interfaces, methods and design patterns.
HLD focuses heavily on scalability, reliability and communication.
LLD focuses heavily on correctness, maintainability and extensibility.
The same topic, such as APIs or databases, can appear at both levels.
HLD normally comes before detailed implementation.
HLD and LLD should remain consistent with each other.
In interviews, stay at the requested level and go deeper when asked.
Start with the overall design, then explore the most important details.