What is Low Level Design? (LLD vs HLD)

Imagine you're planning to build a house.

First, you hire an architect. The architect decides: how many floors will there be? Where does the kitchen sit relative to the living room? How will plumbing and electrical wiring run through the structure? This is the big-picture plan — the blueprint that shows which major parts exist and how they connect to each other.

But the architect's floor plan doesn't tell a carpenter how to build a specific cabinet. It doesn't tell an electrician which gauge wire to run to the kitchen outlet. For that, you need detailed construction drawings — exact measurements, material specs, joint types, and step-by-step assembly instructions for every individual component.

Software engineering works the same way. There are two distinct levels of design:

• High Level Design (HLD) — the architect's floor plan. Which services exist? How do they talk to each other? Where does data live?
• Low Level Design (LLD) — the carpenter's detailed drawings. Which classes exist inside a service? How do objects collaborate? What patterns govern the code's internal structure?

This tutorial introduces both concepts, draws a clear boundary between them, and explains why LLD is the skill that separates engineers who write code from engineers who design software.

High Level Design — also called System Design — is about the architecture of an entire system. It answers questions at the infrastructure and service level:

• Which components exist? A web server, a database, a cache layer, a message queue, a CDN
• How do they communicate? REST APIs, gRPC calls, event-driven messaging, WebSocket connections
• Where does data live? PostgreSQL for transactions, Redis for caching, S3 for file storage, Elasticsearch for full-text search
• How does the system handle scale? Load balancers distribute traffic, horizontal scaling adds more server instances, database sharding splits data across multiple machines

When someone says "Design Twitter" in an HLD interview, they expect you to draw a diagram with boxes like Tweet Service, Timeline Service, Notification Service, CDN, and Database — then draw arrows describing how data flows between them during key operations like posting a tweet or loading a home feed.

HLD does NOT concern itself with:

• Which classes exist inside the Tweet Service
• How the Tweet object relates to the User object at the code level
• Which design pattern the notification system uses internally
• Whether a method is public or private

Think of HLD as the satellite view — you can see continents and oceans, but you can't make out individual streets, buildings, or the wiring inside them.

Low Level Design — also called Object-Oriented Design (OOD) or Machine Coding in some interview contexts — zooms into a single component and designs its internal structure. It answers questions at the class and object level:

• Which classes exist? User, Tweet, Timeline, NotificationService, FeedRanker
• What attributes does each class hold? Tweet has content, author, timestamp, likes_count
• What methods does each class expose? Tweet.like(), Timeline.addTweet(), User.follow(otherUser)
• How do classes relate to each other? A User has many Tweets (composition — if the user is deleted, their tweets go with them). A Tweet is associated with a User (association — the tweet references its author). A FeedRanker depends on a RankingAlgorithm interface (dependency — it uses the algorithm but doesn't own it).
• Which design patterns govern behavior? Observer Pattern for delivering notifications when state changes. Strategy Pattern for swapping feed-ranking algorithms at runtime. Factory Pattern for creating different notification types (email, push, SMS) without hardcoding each one.

When someone says "Design a Parking Lot" in an LLD interview, they expect you to:

1. Clarify requirements with targeted questions (How many floors? Are there different vehicle sizes? Is pricing involved?)
2. Identify classes like ParkingLot, Floor, ParkingSpot, Vehicle, Ticket, PricingStrategy
3. Draw UML class diagrams showing relationships, multiplicities, and key methods
4. Write actual working code with proper OOP structure
5. Explain which design patterns you chose and why they fit this problem

Think of LLD as the street view — you can see individual buildings, the doors and windows, the wiring inside the walls, and the plumbing beneath the floor.

Understanding what each level covers — and what it intentionally ignores — is fundamental before diving deeper into LLD.

A critical insight: you need both, and they complement each other. A system with elegant architecture but poorly designed internal components becomes a maintenance nightmare — every feature request takes weeks, bugs cascade unpredictably, and onboarding new developers feels like deciphering ancient scrolls. Conversely, beautifully designed classes inside a service that can't handle real-world traffic is equally useless.

This course focuses entirely on LLD — the skill of designing clean, extensible, maintainable code at the class and object level. If you're interested in HLD / System Design, CodePeet covers that in a dedicated course.

Let's make the difference tangible. Imagine you're building an e-commerce platform.

The HLD Perspective

At the HLD level, you'd design the overall system:

• A Frontend (web and mobile apps) talks to an API Gateway
• The gateway routes requests to microservices: Order Service, Payment Service, Inventory Service, Notification Service
• Services communicate asynchronously through a Message Queue (Kafka or RabbitMQ)
• Transactional data lives in PostgreSQL, session data in Redis, product images on a CDN

The HLD question is: When a user places an order, how does data flow between these services? What happens if the Payment Service is temporarily unavailable? How do we ensure the inventory count stays accurate across concurrent orders?

Notice how every question is about services, infrastructure, and data flow between systems.

The LLD Perspective

Now zoom into the Order Service and design its internals:

• Which classes exist? Order, OrderItem, OrderStatus, OrderService, PricingStrategy, OrderRepository
• What does Order look like? It has an orderId, a list of OrderItem objects, a status field (an enum tracking its lifecycle), a createdAt timestamp, and methods like calculateTotal(), confirm(), and cancel()
• How is pricing calculated? Using the Strategy Pattern — you can swap between flat-rate, percentage discount, and buy-one-get-one pricing without touching the Order class itself
• How are state transitions managed? Using the State Pattern — PENDING → CONFIRMED → SHIPPED → DELIVERED, with each state object enforcing which transitions are legal and rejecting invalid ones
• How are other services notified? Using the Observer Pattern — when an order is placed, all registered observers (inventory deduction, email notification, analytics event) react independently, and adding a new observer requires zero changes to OrderService

The LLD question is: Design the classes, define their relationships, draw the UML, and write working code.

Don't worry if terms like Strategy Pattern, State Pattern, or Observer Pattern are unfamiliar right now. Every one of them is covered in depth in this course — with code in both Python and Java, UML diagrams, Manim-rendered video walkthroughs, and real-world examples drawn from systems you've actually used.

Software development isn't a single step — it's a pipeline of decisions, each building on the one before it:

1. Requirements Gathering — What does the system need to do? What are the constraints and non-negotiables?
2. High Level Design — Which components will we build, and how will they communicate across the network?
3. Low Level Design — How will we structure the code inside each component? Which classes, relationships, and design patterns will we use?
4. Implementation — Writing the actual code based on the LLD blueprint
5. Testing — Verifying the code behaves correctly under normal conditions, edge cases, and failure scenarios
6. Maintenance — Extending, refactoring, debugging, and fixing the code over the rest of its lifespan

LLD sits right between architecture and code. It is the bridge that transforms abstract system diagrams into concrete, buildable class structures that a developer can sit down and implement.

Without LLD: Developers jump from vague requirements straight to typing code. The result? Classes with 2000 lines doing 15 unrelated things, duplicated business logic scattered across modules, tightly coupled components that break in unexpected places when you change one thing, and a codebase that makes experienced engineers say "I'm afraid to touch that file."

With LLD: Developers think about class responsibilities, relationships, and extension points before writing a single line. The result? Clean, modular code that's straightforward to understand, easy to test in isolation, safe to extend with new features, and possible to hand off to other engineers without a two-week onboarding session.

Here's the surprising part: Step 6 — Maintenance — is where software spends most of its life. Studies consistently show that 60-80% of a software project's total cost is spent on maintenance, not initial development. That means the quality of your LLD directly determines whether maintaining the system is a manageable task or an ongoing crisis. We'll explore this in depth in the next tutorial.

LLD interviews — also called machine coding rounds or object-oriented design rounds — are a standard part of the hiring process at most technology companies. If you're serious about software engineering as a career, you will encounter these.

What Companies Ask

• Large product companies (Google, Amazon, Microsoft, Meta, Uber, Flipkart, Swiggy) — "Design a parking lot system", "Design an elevator system", "Design a ride-sharing service", "Design a chess game"
• Startups — Often a live coding round: "Build a working implementation of this system in 60-90 minutes, and be ready to extend it when we add new requirements"
• Finance and fintech — "Design a stock trading platform", "Design a rate limiter", "Design a digital wallet"

What Interviewers Evaluate

1. Requirement clarification — Can you ask the right questions to narrow scope before writing code? Or do you start coding immediately based on assumptions?
2. Object identification — Can you discover the right classes and abstractions from a vague set of requirements?
3. Relationship modeling — Do you understand composition vs aggregation vs inheritance? Can you model them correctly in a UML diagram?
4. Design pattern application — Do you reach for the right pattern at the right time? More importantly, do you know when a pattern doesn't fit and a simpler approach is better?
5. Code quality — Is your code clean, properly structured, following SOLID principles, and handling edge cases?
6. Trade-off discussion — Can you explain why you chose one approach over another, what you'd change at a different scale, and where your current design would start to break down?

Every single skill on this list is taught systematically in this course. By the time you reach S16, you'll have a complete 4-step interview framework for approaching any LLD problem with clarity and confidence — and you'll have practiced it across 34 real-world design problems in the Design Problems course.

• High Level Design (HLD) is the satellite view — it defines which services, databases, and infrastructure components exist and how they communicate across the network
• Low Level Design (LLD) is the street view — it defines the classes, objects, methods, and relationships inside a single component, producing clean, structured, extensible code
• Both are essential and complementary. HLD without LLD produces a well-architected system filled with unmaintainable spaghetti code. LLD without HLD produces beautiful code inside a system that collapses under real-world load and scale.
• LLD is the foundation skill for every software engineer — not just for interviews, but for your daily work writing, reviewing, and refactoring production code
• This course teaches the complete LLD toolkit: OOP fundamentals (S2-S4), UML diagrams (S5), SOLID and design principles (S6-S7), domain modeling (S8), refactoring (S9), all 23 classic design patterns (S10-S12), architecture and dependency injection (S13), concurrency (S14-S15), and a structured interview framework (S16, S54)
• Next up: In the next tutorial, we'll explore why LLD matters so critically by examining a reality that surprises most developers — up to 70% of a software project's total cost is consumed by maintenance, not initial development, and poor LLD is the primary driver behind maintenance costs spiraling out of control