HLD vs LLD

Introduction

High-Level Design (HLD) and Low-Level Design (LLD) are complementary lenses on the same product. HLD answers what runs where at scale — services, databases, queues, regions. LLD answers how code inside one service is structured — classes, methods, design patterns, thread safety.

Interviewers use prompt wording to signal which lens they want. "Design Twitter" is HLD: feeds, fan-out, caches, sharding. "Design a parking lot in Java" is LLD: Vehicle, Spot, Ticket classes and state transitions. Mixing them — drawing Kubernetes for a parking lot or class diagrams for a global CDN — wastes time and signals inexperience.

This lesson gives you a decision framework, handoff points between architects and developers, and language to switch altitude mid-conversation when the interviewer says "let's zoom into the notification service."

Understanding the topic

Key concepts

• HLD scope: components, network boundaries, data replication, CAP, latency budgets, cost.
• LLD scope: OOP models, SOLID, in-process concurrency, method contracts, unit-testable modules.
• HLD artifacts: architecture diagrams, sequence flows across services, API specs, capacity models.
• LLD artifacts: class diagrams, sequence diagrams within one process, interface definitions.
• Handoff: HLD defines service boundaries and APIs; LLD implements business rules behind those APIs.
• Staff-level rounds often start HLD and drill LLD for one critical component (matching engine, ledger).

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

Internal architecture

Architecture overview

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

Step-by-step explanation

1. Parse the prompt for scale signals (millions of users, multi-region) → default to HLD.
2. Look for single-process domain cues (chess board, vending machine, rate limiter class) → default to LLD.
3. For hybrid prompts, spend 70% on HLD, then pick one hot service for a 5-minute LLD sketch.
4. Ensure every LLD class maps to a responsibility already implied by an HLD API or event.
5. Keep HLD boxes at the service/store level; open an LLD box only when asked to go deeper.
6. Validate consistency: LLD state machines should not violate HLD consistency guarantees.

Informative example

HLD defines the order API contract; LLD implements the service layer inside one Spring Boot application:

// HLD boundary — published OpenAPI / gRPC contract
public record CreateOrderRequest(String userId, List<LineItem> items, String idempotencyKey) {}

public interface OrderApi {
    OrderResponse createOrder(CreateOrderRequest request);
}

// LLD inside order-service JVM
@Service
public class OrderService implements OrderApi {
    private final InventoryClient inventory;
    private final PaymentClient payment;
    private final OrderRepository repository;

    public OrderService(InventoryClient inventory, PaymentClient payment, OrderRepository repository) {
        this.inventory = inventory;
        this.payment = payment;
        this.repository = repository;
    }

    @Override
    @Transactional
    public OrderResponse createOrder(CreateOrderRequest request) {
        inventory.reserve(request.items());
        payment.charge(request.userId(), total(request.items()));
        return repository.save(toEntity(request));
    }
}

In interviews, draw the HLD boxes first (Order Service, Inventory Service, Payment Service). Only expand OrderService class details when the interviewer asks how you would implement it.

Real-world use

Real-world use cases

• Splitting architecture RFCs (HLD) from sprint-level design docs (LLD) in enterprise teams.
• Backend interviews at companies that combine system design + OOD in one loop.
• Refactoring when HLD boundaries no longer match LLD package structure.
• Onboarding: new hires read HLD for context, LLD READMEs for module conventions.

Best practices

• Ask the interviewer which level they want if the prompt is ambiguous.
• Use consistent names between HLD services and LLD packages (order-service → com.app.order).
• Keep HLD diagrams free of class names; keep LLD diagrams free of Kafka topic names unless relevant.
• Document API contracts at the HLD boundary so LLD teams can work in parallel.
• When zooming into LLD, restate which HLD assumptions still hold (sync vs async payment).
• Practice both modes — many candidates over-index on one.

Common mistakes

• Drawing microservices for a clearly single-machine LLD problem.
• Listing design patterns during HLD without a service-level justification.
• Skipping APIs at HLD and jumping straight to database schemas.
• Implementing LLD with classes that span multiple HLD service boundaries.
• Using the same diagram type for both levels — confuses reviewers.

Advanced interview questions

Summary

HLD is distributed architecture; LLD is in-service object design. Prompt wording and scale hints tell you which mode to lead with. Hybrid rounds: mostly HLD, selective LLD on one critical service. API contracts are the clean handoff between the two levels. Use the right diagram for the altitude — services vs classes. TechLearningPRO covers both tracks so you can switch lenses confidently.