High-Level Design (HLD) vs Low-Level Design (LLD)

One of the most common misconceptions among software engineers is believing that architecture and design are the same thing.

They are related.

They influence each other.

But they solve different problems.

Many developers start learning Low-Level Design by studying classes, objects, and design patterns.

Many architects start learning High-Level Design by studying distributed systems, scalability, and system decomposition.

Unfortunately, most people never learn how these two worlds connect.

As a result.

• Architects create designs that developers cannot implement.
• Developers create implementations that violate architectural goals.
• Teams lose consistency.
• Systems become difficult to maintain.

Historical Context

To understand HLD and LLD, we must revisit the Software Crisis.

As software systems grew larger, engineers discovered a fundamental problem:

No human can understand an entire large system simultaneously.

Imagine:

Operating System
10+ million lines

Database
20+ million lines

Enterprise ERP
50+ million lines

Cloud Platform
100+ million lines

Trying to understand everything at once is impossible.

Engineers solved this problem through:

Abstraction

Abstraction allows us to view a system at different levels.

Just as a city can be viewed as:

Country View
    ↓
State View
    ↓
City View
    ↓
Street View
    ↓
Building View
    ↓
Room View

Software can also be viewed at different levels:

Business View
    ↓
Architecture View
    ↓
Module View
    ↓
Class View
    ↓
Method View

HLD and LLD emerged as mechanisms for managing these abstraction levels.

The Fundamental Problem

Imagine you are asked:

Design Amazon

What does that means?

Does it mean:

Servers?
Databases?
Services?
Classes?
Objects?
Methods?
Variables?

The question is too broad.

Before designing, we must choose the level of abstraction.

This is where HLD and LLD come in.

What is High-Level Design (HLD)?

Definition

High-Level Design describes:

The overall structure of a software system.

It focuses on:

• Major components
• Services
• Modules
• Databases
• Communication
• Architectural decisions

It does NOT focus on:

• Classes
• Methods
• Data members
• Internal implementation

HLD Answers Questions Like

What services exist?

How do they communicate?

Which database should be used?

Should we use caching?

How is the system deployed?

How does data flow?

How does the system scale?

Example: Food Delivery System

Suppose we are designing a food delivery platform.

HLD view:

+--------------------+
|     Mobile App     |
+--------------------+
          |
          v
+--------------------+
|      API Gateway   |
+--------------------+
          |
 ---------------------
 |         |         |
 v         v         v

User     Order     Payment
Service  Service   Service

  |         |         |
  --------Database-----

Notice:

We see services.

We do not see classes.

We do not see objects.

We do not see methods.

This is High-Level Design.

Characteristics of HLD

HLD focuses on:

What is Low-Level Design (LLD)?

Definition:

Low-Level Design describes:

The internal design of individual components.

It focuses on:

• Classes
• Objects
• Interfaces
• Methods
• Relationships
• Design patterns

LLD takes a component and explains:

How will this component actually be built?

Example

Suppose HLD contains:

Order Service

LLD answers:

What classes exist?

How do objects collaborate?

What interfaces exist?

Which patterns should be used?

How is extensibility achieved?

LLD Example:

Order Service:

+----------------+
| OrderService   |
+----------------+
        |
        |
        v

+----------------+
| Order          |
+----------------+

+----------------+
| OrderItem      |
+----------------+

+----------------+
| PricingEngine  |
+----------------+

+----------------+
| PaymentManager |
+----------------+

Characteristics of LLD

Visualizing the Difference

Imagine designing a hospital.

HLD View

Hospital

Emergency Wing
Radiology
ICU
Pharmacy
Laboratory
Administration

This describes major departments.

LLD View

Now zoom into Pharmacy.

Medicine
Inventory
Prescription
Pharmacist
StockManager
Supplier

Now we are designing internal structure.

This is LLD.

The Relationship Between HLD and LLD

Many beginners think:

Architecture
OR
Design

Wrong.

The relationship is:

Architecture
    ↓
  Design
    ↓
   Code

Or:

   HLD
    ↓
   LLD
    ↓
Implementation

Each layer refines the previous layer.

System Decomposition

One of the most important engineering skills is decomposition.

What is Decomposition?

Breaking a large problem into smaller problems.

Example:

Instead of building:

Amazon

we build:

User Servie
Order Service
Payment Service
Review Service
Recommendation Service

Then inside Order Service:

Order
OrderItem
Pricing
Tax
Discount

This is decomposition at LLD level.

Why Decomposition Matters

Without decomposition:

Huge Complexity

With decomposition:

Small Manageable Components

This is one of the most important principles in software engineering.

Decision Types in HLD

HLD decisions are strategic.

Examples:

Database Selection

PostgreSQL
MySQL
MongoDB
Cassandra

Communication Style

REST
gRPC
Message Queue

Architecture Style

Monolith
Microservices
Event Driven

Scalability Strategy

Load Balancing
Caching
Replication

Decision Types in LLD

LLD decisions are tactical.

Examples:

Object Relationships

Association
Aggregation
Composition

Design Patterns

Strategy
Factory
Observer
Builder

Class Structure

Inheritance
Composition
Interfaces

Responsibility Assignment

Who owns validation?
Who owns pricing?
Who owns payment?

Example: Payment System

HLD Thinking

Questions:

Should Payment be a separate service?
Should it have its own database?
Should it scale independently?
How do we secure it?

LLD Thinking

Questions:

How do we support multiple payment methods?
How do we extend future gateways?
Should we use Strategy Pattern?
How do classes collaborate?

Different abstraction levels.

Different concerns.