HLD vs LLD

Introduction

High-Level Design (HLD) answers what the system is made of at scale: services, databases, caches, queues, and how they talk across a network. Low-Level Design (LLD) answers how code inside one service is organized: classes, methods, and in-process patterns.

Confusing the two in an interview is a red flag. When asked to design a parking lot, interviewers want class-level modeling — not Kubernetes pods. When asked to design Twitter, they expect HLD first; LLD may appear only for a hot component like a timeline service.

Strong engineers switch lenses deliberately. This lesson gives you a crisp decision framework so you open at the right altitude.

Understanding the topic

Key concepts

• HLD: components, APIs, data stores, replication, CAP trade-offs, latency budgets.
• LLD: classes, interfaces, inheritance vs composition, method signatures, in-memory state.
• HLD diagrams often show boxes and arrows between services; LLD uses class and sequence diagrams.
• Same feature spans both: HLD picks a notification service; LLD models NotificationSender inside it.
• Interview prompts usually signal scope — 'design Uber' is HLD; 'design an elevator controller' is LLD.
• Documentation: HLD in architecture RFCs; LLD in module READMEs and code review packets.

flowchart TB
  HLD[High-Level Design] -->|components APIs scale| LLD[Low-Level Design]
  LLD -->|classes methods patterns| Code

Step-by-step explanation

1. Read the prompt for scale words (millions of users, multi-region) → lean HLD.
2. Look for single-process OOP cues (game board, vending machine) → lean LLD.
3. For full-stack system design, spend most time on HLD, then zoom into one service for LLD.
4. Define boundaries: what is in scope for this exercise vs external systems.
5. Ensure APIs between HLD components are stable before detailing internal classes.
6. Validate that LLD classes map to responsibilities implied by HLD interfaces.

Informative example

HLD might define a REST API; LLD implements the service layer inside one JVM:

// HLD boundary (API contract — could be OpenAPI)
public interface OrderApi {
    OrderResponse createOrder(CreateOrderRequest request);
}

// LLD inside the order service
public final class OrderService implements OrderApi {
    private final InventoryClient inventory;
    private final PricingEngine pricing;
    private final OrderRepository repository;

    public OrderService(InventoryClient inventory, PricingEngine pricing, OrderRepository repository) {
        this.inventory = inventory;
        this.pricing = pricing;
        this.repository = repository;
    }

    @Override
    public OrderResponse createOrder(CreateOrderRequest request) {
        pricing.validate(request.items());
        inventory.reserve(request.items());
        Order order = Order.from(request);
        repository.save(order);
        return OrderResponse.from(order);
    }
}

OrderService is LLD — collaborators are interfaces so HLD can swap remote gRPC clients for in-memory fakes in tests.

Real-world use

Real-world applications

• Staff engineer writes HLD for a new platform; team leads write LLD for each service.
• Interview loop: system design round (HLD) plus OOP design round (LLD).
• Migrating monolith to microservices — HLD splits services; LLD refactors packages.

Best practices

• Ask 'Are we designing the whole system or one component?' in the first two minutes.
• Do not draw database shards when the problem is Snake and Ladder.
• Do not list fifty Java classes when the problem is global CDN routing.
• Keep HLD technology-agnostic until constraints are given.
• In LLD, stay in one process unless explicitly asked about distributed locking.
• Cross-reference: every LLD module should trace to an HLD box or be marked internal utility.

Common mistakes

• Drawing microservices for a chess board LLD question.
• Skipping API contracts and diving into private methods.
• Discussing Kafka partitions in a vending machine interview.
• Treating UML class diagrams as deployment diagrams.

Advanced interview questions

Summary

HLD = system topology; LLD = code structure inside a boundary. Prompt wording and scale hint which lens to use. APIs connect HLD components; classes implement LLD behavior. Ask clarifying questions before drawing. Match diagram type to altitude — no Kafka in a board game.