What is "What is LLD?" about?

Why LLD matters for long-term system survival and how it differs from HLD.

What topics does "What is LLD?" cover?

This article covers: lld basics, software architecture, clean code, extensibility, solid.

What is LLD?

Software engineering is often divided into two worlds. There's the high-flying view from 30,000 feet, where we talk about data centers and millions of users, and then there's the ground-level reality, where we talk about classes, objects, and naming variables.

Most developers focus on the "big stuff," but the secret to a long, successful career: and clearing rounds at top-tier startups: is mastering the "small stuff." This is Low-Level Design (LLD).

The Essentials

If you're in a hurry or just want to revise the "gold nuggets" from this post:

LLD is for Humans: While HLD ensures the system can handle traffic, LLD ensures that your teammates (and your future self) can actually read and change the code.
The 12% Law: Engineers spend only 12% of their day actually writing new code. The rest is spent reading, debugging, and reviewing.
Extensibility is King: Good design allows you to add features without performing "surgery" on the entire codebase.
"Who" over "What": OOP shifts the focus from external procedures to internal object responsibilities, making it more natural for our brains.

Classes as Blueprints: Attributes and Behaviors

Let's look at how we write the blueprint for a Student. In Low-Level Design (and specifically in OOP), we define the information they hold (Attributes) and the actions they can perform (Behaviors).

LLD in Action: The Blueprint Problem

Procedural Mess

Data is passive and scattered. Anyone can touch it. There are no clear "blueprints," leading to a "ball of thread" that breaks easily.

let name = "Denver";
let psp = 90;

function apply(name, psp) {
if (psp > 80) { .. }
}

Hard to track, hard to reuse, and impossible to scale as the system grows.

Low Readability

✓

Object-Oriented Design

Data and actions are bundled into a Class. The object is responsible for its own state. It's clean, isolated, and scalable.

class Student {
  name; psp;
  apply() {
    if (this.psp > 80) { .. }
  }
}

The code mirrors real-world ideas, making it 10x easier for humans to read and fix.

High Maintainability

Code Implementation: The Student Blueprint

Here is how we translate the "Idea" of a Student into a working, extensible piece of code:

class Student {
    name: string;
    batch: string;
    psp: number;

    constructor(name: string, batch: string, psp: number) {
        this.name = name;
        this.batch = batch;
        this.psp = psp;
    }

    changeBatch(newBatch: string): void {
        this.batch = newBatch;
    }

    applyForJob(): void {
        if (this.psp >= 80) {
            console.log("Success! Your application was sent.");
        } else {
            console.log("Keep learning. You need at least 80% PSP.");
        }
    }
}

HLD vs. LLD: The Castle Analogy

Imagine you are building a giant Lego castle.

High-Level Design (HLD) is the instruction manual that shows where the main towers go, how many rooms there are, and where the bridge is. It doesn't care about the shape of a single Lego brick. It cares about how the whole castle fits together so it doesn't fall over when a breeze hits it.

In the real world, HLD is what helps Facebook stay online when a million people visit at once. It's about Infrastructure Layers: Clients, Load Balancers, Application Servers, Caches, and Database Clusters. HLD's main goal is Scaling and Reliability.

Low-Level Design (LLD) is about how we actually write the code inside those servers. It's the "zoom-in" view. Instead of talking about servers, we talk about Classes (blueprints), Methods (actions), and Relationships.

If HLD makes sure the site can handle a million users, LLD makes sure the code is easy for humans to read and fix.

Feature	HLD (Big Picture)	LLD (Small Details)
What it tracks	Servers, Databases, Traffic	Classes, Objects, Patterns
Main Goal	Scaling (Handling more users)	Maintainability (Easy to fix)
Common Name	System Design	Object-Oriented Design (OOD)

The 12% Reality: Why Engineers Read More Than They Write

A common myth is that software engineers spend their whole day typing code. Research shows the opposite: on average, engineers spend only about 12% of their day actually writing new code.

If you work an 8-hour day, that's only one hour spent typing. So, what happens during the other 88% of the time?

Reading Code: You spend hours looking at what your teammates wrote so you can build on top of it.
Debugging: You cannot fix what you do not understand. Debugging is 90% reading and 10% changing code.
Code Reviews: Checking someone else's work. Confusing code leads to "Rubber Stamping" where bugs enter production.
Knowledge Transfer: Explaining your code to a new teammate. Good LLD takes 5 minutes instead of 5 hours.

The quality of your code determines the speed of your team. If your code is a messy "ball of thread," it takes everyone longer to do anything.

Design for the Future: In software, the only constant is change. LLD ensures that your code is both Extensible (easy to add) and Maintainable (easy to fix).

The Manager Scenario: "We need a new feature!"

Imagine your manager comes to your desk on a Friday afternoon: "James, our app only takes Credit Cards. By Monday, we need to support UPI and Bitcoin."

The Bad LLD Way

A single giant file with messy logic. Adding a feature requires surgery.

if (type == "CC") { ... }
else if (type == "UPI") {
// Perform surgery here!
}

Modifying existing code is risky. You might break the Credit Card logic while adding UPI.

Low Maintainability

✓

The Good LLD Way

Each feature is a separate "module". You add features by extending, not modifying.

interface Payment { process(); }
class UPI implements Payment {
// Just add, don't change!
}

Existing code stays untouched. New features are added in minutes without any risk.

High Extensibility

Thinking in Paradigms: Speed vs. Understandability

A Paradigm is just a "way of thinking" or a set of rules for structuring code. While we focus on OOP, it's important to understand the trade-offs.

Procedural Style (Focus on "What"): Fast and low-memory. King for Operating Systems and Embedded Systems.
OOP Style (Focus on "Who"): Industry standard for business software. Much more natural for humans to read.
Functional Style (Data Pipelines): Treats functions like rules. Excellent for processing large lists of data.

Paradigm	Example	Focus
Procedural	`print(student)`	What is being done.
OOP	`student.print()`	Who is doing what.

By mastering LLD and OOP, you aren't just writing code that a computer can run; you are writing a story that other humans can read, grow, and maintain for years to come.

In the next chapter, we'll dive into the first pillar of OOP: Encapsulation, and learn how to protect these ideas from a chaotic world.