HLD vs LLD: Understanding the Blueprint Behind Software What I learned about the two levels of software design, and why a developer should care.

Ankit Talwar — Fri, 13 Nov 2026 12:20:18 +0000

When I started learning software design, two acronyms kept showing up together: HLD (High-Level Design) and LLD (Low-Level Design). They sounded like the same thing at different zoom levels, and honestly, that's close to the truth. This post is my attempt to explain the difference in plain language, with a Python example, based on what I recently studied in AlgoMaster's Low-Level Design course.

The city and the house

The simplest way I found to remember it: building software is like building a city.
Before anyone lays a single brick, someone has to decide where the residential areas go, where the commercial zones sit, how the roads connect them, and where power comes from. That is the city plan, and it is High-Level Design.
Once the plan is approved, an architect picks one plot of land and draws the detailed blueprint for a single house: how many rooms, where the plumbing runs, what the wiring looks like. That is the house blueprint, and it is Low-Level Design.
You need both. A city plan without house blueprints is just a map. House blueprints without a city plan give you a pile of well-built houses with no roads between them. So, both of them have to work together to make something useful work efficiently and smoothly.

What is High-Level Design (HLD)?

HLD defines the architecture of the system. It answers one big question: how should the system be structured, and how will its major parts talk to each other?
The focus is on what the pieces are, not on how each one works inside. Typical HLD questions include:
• What are the major components or services? (user service, payment service, notification service)
• How do they communicate? (REST, gRPC, a message queue like Kafka or RabbitMQ)
• What technology stack fits? (which language/framework, SQL or NoSQL)
• How does the system stay scalable, reliable and available? (load balancers, replication, CDNs)
• Which third-party services are involved? (a payment provider, cloud storage or third party APIs)

The output is usually architecture diagrams, data-flow diagrams and a list of technology choices: the skeleton of the system.

Example: a ride-hailing app. At the HLD level you would sketch separate Passenger, Driver, Matching and Billing services. The Matching service broadcasts ride requests through a message queue. Passengers and drivers exchange live locations over WebSockets. Location data lives in a NoSQL store, while user and billing data sit in a relational database (You may have to show user and user's ride and transaction history). Everything runs in containers on Kubernetes behind load balancers for scaling and smoothnes.

Notice what is missing: not a single class or method is mentioned.

What is Low-Level Design (LLD)?

LLD zooms into one component and turns the abstract plan into something a developer can actually code. This is where you decide the internal structure: classes, their responsibilities, attributes, methods, relationships and design patterns.
LLD questions sound like this:
• Which classes do I need, and what is each one responsible for?
• What attributes and methods does each class have?
• How do the classes relate (inheritance, composition)?
• Which design pattern fits (Factory, Singleton, Strategy)?
• What are the exact method signatures, return types and exceptions?

Example: the Billing Service from the same ride-hailing app. You might define Ride, Invoice, and a PaymentStrategy interface with two implementations, CreditCardPayment and WalletPayment. An Invoice has a Ride (composition - has a relationship). The Strategy pattern lets the rider switch payment methods without touching the invoice logic.

What LLD looks like in Python

Since I mostly write Python, here is a small sketch of that Billing design using an abstract base class:

from abc import ABC, abstractmethod
class PaymentStrategy(ABC):
@abstractmethod
def process_payment(self, amount: float) -> bool:
...

class CreditCardPayment(PaymentStrategy):
def process_payment(self, amount: float) -> bool:
print(f"Charging {amount} to credit card")
return True

class WalletPayment(PaymentStrategy):
def process_payment(self, amount: float) -> bool:
print(f"Deducting {amount} from wallet")
return True

class Ride:
def init(self, ride_id: str, fare: float):
self.ride_id = ride_id
self.fare = fare

class Invoice:
def init(self, ride: Ride, payment: PaymentStrategy):
self.ride = ride # composition: an invoice has a ride
self.payment = payment # strategy: swappable payment method

def pay(self) -> bool:
    return self.payment.process_payment(self.ride.fare)

invoice = Invoice(Ride("R-101", 250.0), WalletPayment())
invoice.pay()

This is LLD in action: concrete classes, clear responsibilities, and a design pattern chosen on purpose. Adding UPI or a gift-card option later means writing one new class, with no changes to Invoice.

How they work together

HLD and LLD are not rivals. They are consecutive steps in one process:

Requirements say what the system must do.
HLD breaks the system into components.
LLD designs the inside of each component.
Code implements the LLD. Skip HLD and your components won't fit together. Skip LLD and each component turns into tangled code that is painful to extend.

My takeaways

• HLD answers "what are the pieces and how do they connect?" LLD answers "how is each piece built?"
• HLD is about services, databases, queues and scaling. LLD is about classes, interfaces, relationships and patterns.
• They are two zoom levels of the same process, and each depends on the other.
• As a Python developer, I'll practise LLD first by modelling small systems with classes and design patterns, then move on to HLD topics like scalability and messaging.

If you are preparing for software interviews, both skills get tested, so it helps to practise them as a pair.