LLD vs HLD: the difference, and which a fresher should learn first

What HLD and LLD are

High-level design (HLD) and low-level design (LLD) are the two layers of software design. The software engineering body of knowledge (SWEBOK, the IEEE Computer Society's reference) calls them architectural design and detailed design. Architectural design, "sometimes called high-level design", "develops top-level structure and organization". Detailed design "specifies each component in sufficient detail to facilitate its construction" (SWEBOK, Chapter 2). The current edition, SWEBOK V4.0, keeps the split: in its Software Design chapter, the section "Software Design Processes" has two topics, High-Level Design and Detailed Design (SWEBOK V4.0 topics).

In practice, HLD answers questions about the whole system: which services exist, how they talk to each other, where data is stored and how the system scales. LLD answers questions about one component: its classes, their responsibilities, the interfaces between them and the design patterns they use. "Low-level design" is the name interview preparation uses for what SWEBOK calls detailed design.

Which comes first: in a project, and in your preparation

HLD and LLD come in different orders depending on who is asking. In a software project, HLD comes first: the architecture is agreed, then each component is designed in detail, and SWEBOK places both between requirements and construction. Every page in Google's top five for "lld vs hld" gave this order when we read them in October 2026, and it is correct for a team building a system.

In a fresher's preparation, LLD comes first. LLD builds on what a B.Tech or MCA student already studies: object-oriented programming, data structures and clean code. HLD builds on experience of systems running at scale, which a student has rarely had. Learning LLD first means that, when you reach HLD, each box in an architecture diagram is something you know how to build. The two orders do not contradict each other: one is the order a project produces design documents, the other is the order a person learns to produce them.

Is LLD important for freshers?

LLD is the design skill Amazon names for entry-level roles. Amazon's page for software development roles for students and graduates says "The skills listed below will help you excel" and lists coding, programming languages, data structures, algorithms and object-oriented design. The page does not mention system design (Amazon, students and grads, read in October 2026). Amazon's page for the next level, SDE II, says "Expect at least one question on software systems design" (Amazon, SDE II Interview Prep).

What this shows is one large employer's own guidance, not a rule for every company: it does not say a fresher never gets an HLD question. Amazon's general list of interview topics names both "Object-oriented design" and "Distributed computing" (Amazon, interview topics). Prepare LLD properly, and know HLD's basic ideas well enough to discuss them.

HLD and LLD example: a rate limiter, designed as LLD

A rate limiter shows LLD and HLD side by side. A rate limiter decides whether a client may make one more request, for example at most three requests a minute. At the LLD level, the rate limiter is a set of classes. The rest of the app calls one class, RateLimiter. The rule for counting is a separate strategy behind an interface, so a fixed window and a token bucket can be swapped without touching the code that calls the limiter. This is the strategy pattern, and the interface is what SOLID's open-closed principle asks for: new rules are added as new classes, not by editing old ones.

from abc import ABC, abstractmethod
import time


class RateLimitStrategy(ABC):
    """Decides whether one client may make one more request now."""

    @abstractmethod
    def allow(self, client_id: str, now: float) -> bool: ...


class FixedWindow(RateLimitStrategy):
    """At most `limit` requests in each window of `window_seconds`."""

    def __init__(self, limit: int, window_seconds: float):
        self.limit = limit
        self.window_seconds = window_seconds
        self.counts: dict[tuple[str, int], int] = {}

    def allow(self, client_id: str, now: float) -> bool:
        window = int(now // self.window_seconds)
        key = (client_id, window)
        if self.counts.get(key, 0) >= self.limit:
            return False
        self.counts[key] = self.counts.get(key, 0) + 1
        return True


class TokenBucket(RateLimitStrategy):
    """Bursts up to `capacity`, refilled at `rate` tokens per second."""

    def __init__(self, capacity: int, rate: float):
        self.capacity = capacity
        self.rate = rate
        self.buckets: dict[str, tuple[float, float]] = {}  # client -> (tokens, last)

    def allow(self, client_id: str, now: float) -> bool:
        tokens, last = self.buckets.get(client_id, (self.capacity, now))
        tokens = min(self.capacity, tokens + (now - last) * self.rate)
        if tokens < 1:
            self.buckets[client_id] = (tokens, now)
            return False
        self.buckets[client_id] = (tokens - 1, now)
        return True


class RateLimiter:
    """The class the rest of the app calls. The strategy is swappable."""

    def __init__(self, strategy: RateLimitStrategy, clock=time.monotonic):
        self.strategy = strategy
        self.clock = clock

    def allow(self, client_id: str) -> bool:
        return self.strategy.allow(client_id, self.clock())


if __name__ == "__main__":
    fake_now = [0.0]
    clock = lambda: fake_now[0]

    fixed = RateLimiter(FixedWindow(limit=3, window_seconds=60), clock)
    print("fixed window:", [fixed.allow("user-1") for _ in range(4)])
    fake_now[0] = 60.0
    print("next window: ", fixed.allow("user-1"))

    fake_now[0] = 0.0
    bucket = RateLimiter(TokenBucket(capacity=3, rate=1.0), clock)
    print("token bucket:", [bucket.allow("user-1") for _ in range(4)])
    fake_now[0] = 1.0
    print("after 1 s:   ", bucket.allow("user-1"))

Run with Python 3.12, it prints:

fixed window: [True, True, True, False]
next window:  True
token bucket: [True, True, True, False]
after 1 s:    True

The fixed window allows three requests, refuses the fourth and allows requests again when the next minute starts. The token bucket allows a burst of three, refuses the fourth and allows one more after a second, once a token has refilled. The clock is passed in, so the example runs the same way every time. These are the choices an LLD design is judged on: the classes, what each is responsible for, the interface and whether the code is easy to extend and test.

HLD and LLD example: the same rate limiter, designed as HLD

At the HLD level, a rate limiter stops being a set of classes and becomes a component of a system, and the questions change. Where does the rate limiter run? In front of the application: in an API gateway or a middleware layer that every request passes through, so rejected requests never reach the application code.

Where do the counts live? A rate limiter written as classes for one server, like the LLD version, keeps its counts in the memory of one process. Once the application runs on several servers, each server counts separately and a client could make three requests on each one. The counts move to a store every server shares, such as Redis, and reading and updating a count has to happen as one atomic step, or two servers can both let the same extra request through.

What happens when that shared store is down? Failing open lets every request through without a limit; failing closed rejects every request. The right choice depends on what the rate limiter protects. And what does a rejected client see? HTTP status 429, which "indicates that the user has sent too many requests in a given amount of time", and the response "MAY include a Retry-After header indicating how long to wait" (RFC 6585). None of these HLD questions is about classes. They are about where components sit, shared state, failures and trade-offs.

Which is harder, LLD or HLD?

LLD and HLD are hard in different ways, and a rate limiter designed at both levels shows how. The LLD design has right and wrong answers you can check: the code runs, the counting strategy can be swapped, and a test with a fake clock proves the behaviour. A student can practise LLD alone, with a laptop. The HLD design has no single right answer: failing open or closed, a gateway or a middleware, depend on what the system is for, and judging those trade-offs comes from seeing systems run and fail. That is why HLD tends to be harder for a fresher, who has rarely seen a system in production, and why it is learnt after LLD.

Four design problems for a fresher to practise

Prokopi Vanguard's LLD practice list has four design problems: a parking lot, a rate limiter, a URL shortener and an elevator system. When we searched Google for "system design for freshers" in October 2026, its AI answer named the same four as fresher practice problems. Each tests a different part of LLD.

Each of the four also has an HLD version. A URL shortener, for example, raises HLD questions about storage, caching popular links and handling many more reads than writes. Practise the LLD version first.

How Prokopi Vanguard orders system design

Prokopi Vanguard, Prokopi's 10-month AI engineering program for B.Tech and MCA students, teaches system design in this order. Its module "System Design — LLD & HLD", about four weeks, starts with low-level design (OOP design, SOLID principles, design patterns such as factory, singleton, observer and strategy, and UML and class diagrams), then LLD practice on four problems (a parking lot, a rate limiter, a URL shortener and an elevator system), then high-level design (scalability, caching layers, database sharding and replication, the CAP theorem and message queues), and ends with design interview skills. It is the ninth of the program's ten modules. The eight before it are Python, DSA, CS fundamentals, backend engineering with FastAPI and PostgreSQL, and four AI modules (LLM fundamentals, RAG, agentic AI and productionising AI), so students reach system design already writing classes and APIs. The full curriculum is on the Prokopi Vanguard page.