00:00

Help Us Improve

We're sorry this tutorial wasn't helpful. Please tell us what we can do better.

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

Last updated:

In system design interviews and real-world projects, two important concepts are often discussed: High-Level Design (HLD) and Low-Level Design (LLD). Both are essential, but they serve different purposes.

This tutorial explains them in simple terms, compares them side by side, and walks through one complete example: the HLD of an online shopping application and the LLD of its Order Service, with a class diagram, a sequence diagram and a database schema.

1. What Is High-Level Design (HLD)?

High-Level Design focuses on the big picture of the system. It explains what components exist and how they interact, without going into coding or implementation details.

Key points of HLD

  • Shows the overall system architecture.
  • Identifies the major components and services.
  • Explains the data flow between components.
  • Records technology choices, such as databases, caches and message queues.
  • Covers scalability, availability and reliability.

HLD answers the question: “How does the system work as a whole?”

2. What Is Low-Level Design (LLD)?

Low-Level Design focuses on detailed implementation. It explains how each component is built internally, and is much closer to actual coding.

Key points of LLD

  • Class diagrams and object relationships.
  • Method names and responsibilities.
  • Database table structure.
  • Design patterns used.
  • Error handling and validations.

LLD answers the question: “How exactly will this be implemented?”

3. HLD vs LLD: Quick Comparison

AspectHigh-Level Design (HLD)Low-Level Design (LLD)
FocusOverall system structureDetailed implementation
Main questionWhat are we building?How exactly do we build it?
LevelAbstractDetailed
ScopeThe whole systemOne component or service at a time
AudienceArchitects, stakeholders, team leadsDevelopers and testers
Includes code?NoYes, or very close to code
Design diagramsArchitecture and data flow diagramsClass, sequence and entity-relationship diagrams
Decisions madeServices, databases, caches, queues, protocolsClasses, methods, tables, indexes, patterns
When it is doneFirst, right after requirementsAfter the HLD is agreed

4. Where HLD and LLD Fit in the Design Process

From requirements to code Four steps from left to right: requirements, then high-level design covering components, data flow and technology choices, then low-level design covering classes, methods, tables and patterns for each component, then code and tests. A feedback arrow runs from low-level design back to high-level design. Requirementswhat it must do,and how well High-Level Designcomponents, data flow,technology choices Low-Level Designclasses, methods,tables, patterns Code and teststhe actualimplementation feedback: split or adjust components done once for the whole systemdone for each component
Figure 1: The HLD is created once for the whole system; an LLD is then written for each component. Lessons from the LLD can feed back into the HLD.

Feedback flows back up as well: if writing the LLD shows that a component is doing too much, you may split it in the HLD. See System Design Process and Methodologies for the full process.

5. Non-Functional Requirements and Capacity Estimation

A good HLD is shaped as much by how well the system must work as by what it must do. These quality targets are called non-functional requirements:

  • Scalability: how many users and requests the system must handle, now and in future.
  • Availability: how much downtime is acceptable, for example 99.9% uptime, which allows about 8.8 hours of downtime per year.
  • Latency: how fast responses must be, for example "product pages load in under 200 ms".
  • Consistency: whether every user must always see the very latest data, or whether a short delay is acceptable.
  • Security and compliance: how data is protected and which rules apply, such as storing card data safely.

The HLD then uses a quick capacity estimate to choose the right building blocks. A rough calculation for the shop is enough:

Back-of-the-envelope estimate 
Daily active users        : 1,000,000
Product page views / user : 10 per day   -> 10,000,000 views per day
Average read traffic      : 10,000,000 / 86,400 s  = about 116 requests/second
Peak traffic (10x average): about 1,160 requests/second

Orders per day            : 50,000       -> about 0.6 orders/second (peak ~6/s)
Storage per order         : about 2 KB   -> 100 MB per day, about 36 GB per year

These numbers lead straight to HLD decisions: reads far outnumber writes, so the Product Catalog gets a cache; peak traffic needs several servers behind a load balancer; and order storage grows slowly enough for a single relational database to cope for years. None of this needs class names; that detail comes later, in the LLD.

6. HLD Example: Online Shopping Application

For an online shopping application, the HLD shows these building blocks:

HLD of an online shopping application Web and mobile apps send requests through a load balancer to an API gateway, which handles routing and authentication. The gateway routes to four services: the user service with its users database, the product catalog service with its products database and cache, the order service with its orders database, and the payment service, which calls an external payment gateway. The order service also publishes an order placed event to a message queue, which the notification service reads. Web / Mobile apps Load Balancer API Gatewayrouting · authentication User Service Users DB Product Catalog Products DB + cache Order Service Orders DB Payment Service Payment gateway external system Message queue reads "order placed" events Notification Service
Figure 2: The HLD shows the building blocks and how they connect: services, the data each one owns, the external payment gateway and the message queue for events. It contains no class names or table columns.
ComponentResponsibility
Load BalancerSpreads traffic across servers
API GatewaySingle entry point; routing and authentication
User ServiceAccounts, login and profiles
Product Catalog ServiceProducts and prices, with a cache for fast reads
Order ServiceCreates and tracks orders
Payment ServiceTalks to the external payment gateway
Message queueCarries “order placed” events to other services, such as notifications

The HLD also describes the main flows. Placing an order works like this:

  1. The app sends the order to the API Gateway, which checks the user is logged in.
  2. The Order Service reads current prices from the Product Catalog Service.
  3. The Payment Service charges the customer through the payment gateway.
  4. The Order Service saves the order and publishes an “order placed” event.
  5. The Notification Service receives the event and emails the customer.

Notice what is not here: no class names, no method signatures and no table columns. Those belong in the LLD.

7. LLD Example: Designing the Order Service

Now zoom into one box from the HLD: the Order Service. Its LLD defines the classes and how they work together:

Class diagram of the Order Service OrderController uses OrderService, which uses the OrderRepository interface with save and findByCustomerId methods. OrderService creates Order objects and the repository saves and loads them. An Order has an id, customer id, status and a list of items, with methods addItem, total and markPaid. Each Order contains many OrderItem objects with product id, quantity, unit price and a subtotal method. Order has an OrderStatus, an enum with the values created, paid, shipped, delivered and cancelled. OrderController + placeOrder(request) OrderService - orderRepository + placeOrder(customerId, lines) «interface» OrderRepository + save(order) + findByCustomerId(id) Order - id: Long - customerId: Long - status: OrderStatus - items: List<OrderItem> + addItem(productId, qty, price) + total(): BigDecimal + markPaid() OrderItem - productId: Long - quantity: int - unitPrice: BigDecimal + subtotal(): BigDecimal «enum» OrderStatus CREATED PAID SHIPPED DELIVERED CANCELLED uses uses creates saves / loads 1*contains has a
Figure 3: The LLD class diagram for the Order Service. Boxes show each class's fields (−) and methods (+); arrows show which class uses, creates or contains which.

8. Following One Request Through the LLD

A sequence diagram shows the order in which objects call each other for one use case. Here is “place an order” in the LLD:

Sequence diagram for placing an order Six participants: client, OrderController, OrderService, Order, OrderRepository and the database. The client sends POST /api/orders to the controller, which calls placeOrder on the service. The service creates a new Order, adds each item, and calls save on the repository, which inserts the order and its items into the database. The saved order is returned to the service, then to the controller, which replies 201 Created to the client. Client OrderController OrderService Order OrderRepository Database 1. POST /api/orders 2. placeOrder(...) 3. new Order(...) 4. addItem(...) × n 5. save(order) 6. INSERT ... 7. saved order 8. order 9. 201 Created solid arrows = calls · dashed arrows = returns
Figure 4: The sequence diagram follows one use case, placing an order, through the classes in time order, from the HTTP request down to the database and back.

9. Database Design in HLD and LLD

Database design is split between the two levels:

HLD decidesLLD decides
SQL or NoSQL, and which productTables or collections and their fields
Which service owns which dataPrimary keys, foreign keys and constraints
Replication and backupsIndexes for the most common queries
Sharding or partitioning strategyColumn types, lengths and default values
Caching strategyWhich queries hit the cache, and cache keys

For the Order Service, the LLD turns the Order and OrderItem classes from the class diagram into this schema:

schema.sql 
CREATE TABLE orders (
    id           BIGSERIAL    PRIMARY KEY,
    customer_id  BIGINT       NOT NULL,
    status       VARCHAR(20)  NOT NULL,
    created_at   TIMESTAMP    NOT NULL
);

CREATE INDEX idx_orders_customer ON orders (customer_id);

CREATE TABLE order_items (
    id          BIGSERIAL      PRIMARY KEY,
    order_id    BIGINT         NOT NULL REFERENCES orders (id),
    product_id  BIGINT         NOT NULL,
    quantity    INT            NOT NULL CHECK (quantity > 0),
    unit_price  NUMERIC(10, 2) NOT NULL
);

The index on customer_id exists because the LLD knows that “show my orders” is a common query, served by findByCustomerId().

10. Diagrams Used in HLD and LLD

LevelDiagramShows
HLDArchitecture diagramServices, databases, caches and how they connect
HLDData flow diagramHow data moves through the system for a use case
HLDDeployment diagramServers, regions, containers and networks
LLDClass diagramClasses, fields, methods and relationships
LLDSequence diagramThe order of calls between objects for one use case
LLDEntity-relationship (ER) diagramTables and how they relate
LLDState diagramThe states of an object and the allowed changes, such as CREATED → PAID

11. Common Mistakes to Avoid

MistakeBetter approach
Starting with classes and tables before the architecture is clearAgree on the HLD first, then write the LLD for each component
Putting class-level detail in the HLDKeep the HLD at the level of components and data flow
Writing an LLD that is just the codeExplain responsibilities, relationships and decisions, not every line
Ignoring error handling and edge cases in the LLDList what can go wrong and how each case is handled
Never updating the documentsKeep HLD and LLD in step with the real system
Over-designing for problems you do not haveDesign for the known requirements and expected growth

12. Summary

High-Level Design and Low-Level Design are both crucial parts of system design. HLD gives a clear architectural vision: the components, how they connect and which technologies they use. LLD ensures correct and efficient implementation: the classes, methods, tables, patterns and error handling inside each component.

  • HLD decides the components, data ownership, technologies and non-functional targets, often guided by a quick capacity estimate.
  • LLD designs each component's classes, methods, tables, patterns, states and error handling.
  • Architecture and data-flow diagrams belong to HLD; class, sequence and entity-relationship diagrams belong to LLD.

Understanding both helps in building scalable systems and performing well in interviews. For best results, always start with HLD and then move to LLD.