Picture a box of building bricks with a picture on the front showing a finished spaceship. That picture is enough to get you excited, and it tells you roughly what you are building — a cockpit here, wings over there, engines at the back. But the picture alone cannot actually help you build it. For that, you need the instruction booklet tucked inside: page after page showing exactly which brick to pick up, exactly where it clicks into place, and in exactly what order, step by step, until the spaceship in the picture becomes the spaceship in your hands.

In software, the picture on the box is the High-Level Design — the big shapes and how they fit together. The instruction booklet, with every precise step spelled out, is the Low-Level Design, usually shortened to LLD. It is the plan that turns “we need an Order Service” into “here is exactly which classes the Order Service is made of, what each one is responsible for, and exactly how they will behave when a real order comes in.”

Neither version replaces the other. A cook who only has the vague plan will likely ruin the cake through guesswork; a cook who only has exact measurements but no idea what dish they are even making is equally lost. Good software, just like a good cake, needs both the big picture and the precise steps — and LLD is where the precise steps finally get written down.

What makes LLD particularly interesting is that it is the last stop before code. Once an LLD is settled, translating it into a working program is mostly a matter of typing — the hard thinking has already happened. That is precisely why getting it right matters so much: a mistake at this stage does not just linger as an awkward diagram, it gets baked directly into the actual software people will use, bug fixes and all.

In plain words, Low-Level Design is the detailed plan for exactly how one part of a system will be built internally — the classes and objects it is made of, the information each one holds, the actions each one can perform, and precisely how they cooperate to get a job done. Where High-Level Design draws big boxes labelled “Order Service” or “Payment Service,” Low-Level Design opens up one of those boxes and draws everything happening inside it.

LLD lives very close to the actual code — close enough that, in many cases, a developer can look at a well-written LLD and translate it into working code almost line by line. It typically includes class diagrams (showing the objects in the system and how they relate), sequence diagrams (showing the exact order in which those objects talk to each other while completing a task), and enough written detail about edge cases and error handling that surprises are rare once coding actually begins.

A helpful way to remember it: LLD answers “exactly which drawer holds the spoons, and exactly how does the drawer’s handle work?” It assumes the kitchen’s layout — the big picture — has already been decided elsewhere. LLD is not about deciding whether to have a kitchen; it is about making sure every drawer, hinge, and handle inside it works exactly as intended.

It is also worth knowing what LLD is not. It is not a restatement of the big-picture architecture — that job belongs to the HLD, and a good LLD simply assumes that groundwork is already settled. And it is not the finished, running code either, even though it sits very close to it. It is the careful, thought-through plan that comes just before the code, catching mistakes in the design of a class before those mistakes get baked into thousands of lines that are much harder to unravel later.

There is a quieter benefit too, one that only shows up later: a clear LLD makes testing far easier. If a class has one clear, well-defined job, it is straightforward to write a handful of tests that check whether it does that job correctly. A class that secretly does five different things is nearly impossible to test thoroughly, because every test has to account for all the ways its tangled responsibilities might interact. Good LLD, in other words, is not just a favour to the developer writing the code — it is a favour to everyone who will need to trust that code later.

It is entirely possible to sit down and start typing code the moment a feature is assigned, without sketching any classes first. Plenty of small tasks genuinely do not need more than that. But the moment a feature has more than a couple of moving parts — several kinds of objects that need to cooperate, various edge cases to handle, other developers who will touch the same code later — skipping this step tends to show up as pain much sooner than people expect.

There is a team-shaped reason too. When no one has thought through the exact design of a feature, every developer touching it tends to invent their own local conventions — one person’s class does too much, another’s does too little, and a third quietly duplicates logic that already exists somewhere else. A shared LLD acts like a shared blueprint for the instruction booklet itself: everyone builds toward the same precise plan, rather than each person guessing at their own version of “precise.”

Here is a small, familiar story. A developer is asked to add a “cancel order” button to an app that already lets customers place orders. Without a moment spent thinking through the design, they bolt the cancellation logic directly onto the same class that handles placing an order, because that class was already open in the editor. Six months later, someone needs to add a “reorder” feature, and discovers that cancelling, placing, and now reordering logic are all tangled together inside one enormous, fragile class that nobody wants to touch. A few minutes of low-level design at the very start — deciding that order placement, cancellation, and history each deserve their own clearly bounded responsibility — would have prevented the tangle entirely.

None of this means every single function needs a formal design session. Plenty of small, obvious changes are genuinely safe to just make. The judgment call worth developing is noticing the difference — a one-line fix to a typo does not need a class diagram, but a new feature that will introduce new objects, new relationships, or new rules almost always benefits from ten quiet minutes of thinking before the first line of code gets typed.

These three terms sit on the same ladder, each one zooming in further than the last. Here is how they line up, using our Lego spaceship again.

There is no perfectly sharp line between HLD and LLD — reasonable engineers can and do disagree about exactly where one ends and the other begins. A useful rule of thumb: a decision belongs to LLD if changing it stays contained inside one component, without forcing other components to change too. If undoing the decision would mean redrawing the big picture, it was really an HLD decision wearing an LLD costume.

This distinction saves real time in practice. A product manager reviewing a project does not want to wade through class diagrams to understand the shape of a system, and a developer about to write code does not want to dig through paragraphs of business goals to find the one exact detail they need. Keeping HLD and LLD as two separate, clearly labelled documents means each reader lands exactly where they need to be.

It also helps to notice how the three levels differ in how often they change. Requirements shift when the business’s needs shift — sometimes rarely. HLD shifts when the system’s scale or shape genuinely changes — less often than you would think, once a good foundation is in place. LLD, by contrast, tends to shift the most often of the three, since it sits closest to the messy, ever-changing details of real code, real bugs, and real edge cases discovered along the way. Expecting LLD to stay perfectly static is a bit like expecting a recipe to never need a pinch more salt after the first taste-test.

Just like HLD documents share a common shape no matter who writes them, LLD documents tend to include the same handful of ingredients. Here is what you would typically find inside one.

Classes and Objects

At the heart of most LLD work is figuring out the classes a program needs — think of a class as a cookie cutter, and an object as one cookie made from it. A “Book” class might describe the shape every book object will share (a title, an author, a page count), while each actual book in a library system is a separate object made from that same cutter.

Relationships Between Classes

Classes rarely stand alone — they lean on each other. A “Member” borrows a “Book.” A “Car” has an “Engine.” A “SportsCar” is a special kind of “Car.” Working out these relationships precisely, and drawing them clearly, is one of the central jobs of LLD, because getting a relationship wrong is one of the most common sources of tangled, hard-to-change code.

A useful question to ask about any two related classes is: “if one of these disappeared, would the other one still make complete sense on its own?” A Book still makes sense without any particular Library owning it, which points toward a loose relationship. An Engine, on the other hand, rarely makes sense floating around without some Car it belongs to, which points toward a tighter one. Answering this question honestly, for every pair of related classes, tends to produce a design that mirrors how the real-world things actually relate to each other — which is usually the design that holds up best over time.

The Rest of the Ingredients

A good LLD document does not try to describe literally every line that will ever be written — that would simply be the code itself. It needs to be detailed enough that a developer could sit down and write that code with very few open questions left, while still leaving room for small implementation choices that genuinely do not matter at the design level.

One habit worth adopting early: write down the assumptions behind a design, not just the design itself. “We are assuming a member can only borrow up to five books at once” might feel obvious while the design is fresh in someone’s mind, but six months later, a different developer extending the feature has no way of knowing whether that limit was a deliberate business rule or an accidental oversight. A single sentence of written assumption can save an entire afternoon of confused investigation later.

Over many years of building software, engineers noticed that some ways of designing classes led to code that stayed easy to work with, while other ways led to code that slowly turned into a tangled mess. They collected the good habits into five simple ideas, nicknamed SOLID — one letter for each idea. None of them are complicated once you see them through an everyday lens.

It helps to think of these five ideas less like strict laws and more like the advice a wise, experienced builder might give a younger one: not “you must do this or the whole house collapses,” but “here is what tends to go wrong if you do not, based on watching a lot of houses over a lot of years.”

S — Single Responsibility

Each class should have exactly one job, and one reason to ever need changing. Imagine a single kitchen appliance that tried to be a toaster, a blender, and a coffee machine all at once — the moment one part breaks, you lose all three functions, and fixing it becomes a nightmare. A class that only toasts is far easier to understand, fix, and trust.

O — Open for Extension, Closed for Modification

It should be possible to add new behaviour without rewriting existing, already-tested code. Think of a power strip: adding a new lamp means plugging it into a spare socket, not cutting open the wall wiring. Well-designed classes let new features “plug in” alongside existing ones, rather than forcing edits to code that already works.

L — Liskov Substitution

If one class is a specialised version of another, it should be usable anywhere the general version is expected, without surprises. If “Ostrich” is built as a kind of “Bird,” but Birds are expected to be able to fly, then Ostrich quietly breaks that expectation — a sign the classes need rethinking. A specialised version should never secretly betray the promises made by the general one.

I — Interface Segregation

Nobody should be forced to depend on abilities they do not actually use. A universal remote control with two hundred buttons for a device that only ever needs three is confusing and error-prone. Smaller, focused sets of abilities — like a few clearly labelled interfaces instead of one giant one — keep things easier to understand and safer to use correctly.

D — Dependency Inversion

Big, important pieces of a system should not be tightly wired to the small, specific details underneath them. A lamp does not care whether the electricity behind the socket comes from a solar panel or the city grid — it just needs power through a standard plug. Designing classes to depend on general, standard connections rather than specific implementations makes it far easier to swap one part out later without breaking everything around it.

Good design is not about writing clever code — it is about writing code that is still easy to change a year from now.

None of these five ideas need to be memorised as strict definitions to be useful. What matters is the underlying instinct they all share: keep responsibilities narrow, keep the connections between classes loose rather than tightly knotted together, and design so that tomorrow’s changes stay contained rather than rippling outward into everything else. That instinct, more than any acronym, is what separates code that ages gracefully from code that becomes a burden.

Just as architecture has reusable big-picture patterns, LLD has its own set of reusable, smaller-scale solutions called design patterns — tried-and-tested answers to problems that show up again and again while designing classes. They were first collected and popularised by a group of software engineers in the 1990s, and the names have stuck around ever since because the underlying problems they solve simply never go away.

None of these patterns are mandatory — reaching for one when it is not actually needed can make simple code needlessly complicated. The real skill is recognising the shape of a problem and remembering, “oh, this is exactly the kind of situation the Observer pattern was built for,” rather than forcing a favourite pattern onto every design regardless of fit.

It is worth noticing how closely patterns and principles work together. The Strategy pattern, for instance, is really just a concrete way of putting the Open/Closed principle into practice — it lets new behaviour be added by plugging in a new strategy, without editing the class that uses it. Learning patterns without understanding the principles behind them tends to produce someone who can recognise shapes but not judge when those shapes actually fit. Learning the principles first, and picking up patterns as concrete examples of them in action, tends to build a much sturdier instinct for good design.

To avoid every engineer inventing their own private way of drawing classes, the software world largely agreed on a shared visual language called UML — Unified Modeling Language. You do not need to memorise all of it, but a handful of symbols show up constantly. Learning just these few symbols is a bit like learning a handful of traffic signs before driving in a new country — a small investment that instantly makes every diagram anyone else has drawn easier to read.

Inheritance (the hollow-triangle arrow) means one class is a specialised version of another — a Dog “is a” kind of Animal, inheriting its general traits automatically. Composition (the filled diamond) means one object is made up of another, and the two share a tightly bound life — a Car “has a” Engine, and the engine typically does not make sense existing on its own outside that car. Aggregation (the hollow diamond) is a looser version of the same idea — a Library “has” Books, but those books can easily exist independently of any one particular library.

Sequence Diagrams

While a class diagram shows the shape of the objects, a sequence diagram shows them in motion — the exact order of calls that happen while one specific task is carried out.

Reading a sequence diagram is a bit like reading sheet music for a small band — each vertical line is one player, and the horizontal arrows show exactly when each player comes in, in what order, so the whole piece comes together correctly.

Sequence diagrams are especially valuable for the trickiest flows — the ones involving several classes cooperating, or a process that can succeed or fail in a few different ways. For a simple, single-class action, a sequence diagram is usually overkill; for something like “what happens across five different classes when a payment fails halfway through,” it is often the single clearest way to make sure everyone agrees on the exact plan before any code gets written.

Just like HLD, writing a Low-Level Design happens in stages, each one narrowing a fuzzy idea into a precise, buildable plan.

1. 1. Start from the HLD

   Understand which component is being designed, and what it is expected to do within the bigger system.

2. 2. Identify the nouns

   List the real-world “things” involved — a Book, a Member, an Order — since these usually become the classes.

3. 3. Assign responsibilities

   Decide what each class is responsible for, aiming for one clear job per class rather than a jumble of unrelated duties.

4. 4. Draw the relationships

   Work out which classes inherit from others, which contain others, and which simply know about each other.

5. 5. Trace the key flows

   Pick the most important use cases and sketch a sequence diagram showing exactly how objects cooperate to complete each one.

6. 6. Think through edge cases

   Ask what happens when something unusual occurs — an empty input, a missing record, two people acting at the same instant.

7. 7. Review against design principles

   Check the design against ideas like SOLID, watching for classes that are quietly doing too much.

8. 8. Write it down and get feedback

   Share the diagrams and reasoning with the team before writing the real code, so problems are caught while they are still cheap to fix.

That final step matters more than it might seem. A design that only exists as a rough sketch on a single developer’s notepad is easy to overlook flaws in — a second pair of eyes, unfamiliar with the assumptions already made, is remarkably good at spotting the one edge case everyone else missed.

It is also worth saying that these eight steps rarely happen in a perfectly straight line. Sketching a sequence diagram in step five sometimes reveals that a responsibility from step three actually belongs to a different class entirely, which sends the designer back to revise the relationships from step four. That back-and-forth is not a sign of doing it wrong — it is the design genuinely improving as it gets examined from a few different angles.

Let us bring all of this together with a classic, real-feeling example — the low-level design of a system that manages a multi-level parking lot.

Step 1 — The requirement, in plain words

The system should let a vehicle enter, be assigned an available spot appropriate for its size, receive a ticket, and later pay and exit through a gate that raises once payment is confirmed.

Step 2 — Spotting the nouns, and turning them into classes

Step 3 — The class diagram

Step 4 — Tracing what happens when a car enters

A car pulls up. The ParkingLot receives the vehicle and asks itself: is there a free spot of the right size? It searches its collection of ParkingSpot objects for one that is unoccupied and large enough. Once found, it marks that spot as occupied, creates a new Ticket recording the entry time and the assigned spot, and hands that ticket back to the driver. Every one of these steps belongs to a specific class with a specific job — nothing is left vague or shared awkwardly between classes that should not need to know about each other.

Step 5 — Choices worth writing down, and why

Step 6 — What if two cars arrive at the same instant?

A careful LLD does not stop once the happy path works. What happens if two vehicles both request the very last available spot at almost the same moment? Without thinking this through, a system might accidentally assign the same spot to both cars. A well-designed ParkingLot class handles this by making the “find and reserve a spot” step a single, uninterruptible action — so the second car’s request simply sees that the spot is already gone, and moves on to the next available one, rather than colliding with the first. Working through moments like this on paper, before any code exists, is exactly the kind of careful thinking that separates a system people trust from one that occasionally embarrasses its makers.

This is exactly what good LLD looks like in practice: not just class boxes on a page, but a set of deliberate, explainable decisions that keep the system easy to extend later — say, adding electric vehicle charging spots — without having to redesign everything from scratch.

Once you can spot an LLD in one system, the same careful, precise thinking turns up everywhere, just aimed at different objects and rules.

Online Banking

A funds-transfer feature’s LLD carefully separates the class that validates an account from the one that actually moves money, and from the one that records the transaction in history — so that a bug in the display of transaction history can never accidentally allow an unvalidated transfer to slip through.

Ride-Hailing Apps

A “match nearest driver” feature typically has its own tightly focused class whose only job is comparing locations and distances, kept deliberately separate from the classes handling payment or trip history, so that improving the matching logic later never risks breaking billing.

E-Commerce Checkout

A checkout flow’s LLD often uses a Strategy-pattern-style design so that “apply a discount code,” “apply a loyalty reward,” and “apply a bulk discount” can each be added or changed independently, without one messy class trying to handle every possible kind of discount inside a single tangled block of logic.

Hospital Appointment Systems

Here, a class representing an Appointment is usually deliberately kept separate from a class representing a Patient’s medical record, even though the two are closely related — because the rules about who can view each one are very different, and mixing their responsibilities would make those rules far harder to enforce correctly.

Video Games

A game’s LLD often gives every character a shared set of basic abilities — moving, taking damage, interacting with objects — defined once in a general class, while special abilities specific to one character type are added separately. This is the Liskov substitution and single-responsibility ideas in direct action: swap one character for another, and the game’s core logic keeps working without needing to know which specific character it is dealing with.

As with HLD, nothing fancy is strictly required — a notebook and a pencil can sketch a perfectly usable first class diagram. But once it is time to share a design cleanly with a team, a few tools show up again and again.

Whichever tool is used, sticking to standard UML symbols pays off — a hollow-triangle arrow means the same thing to every engineer who has learned it, the same way a stop sign means the same thing to every driver, no matter which city they learned to drive in.

A quiet but genuinely useful habit is keeping diagrams alongside the actual code, rather than buried in a separate, rarely-visited folder. Diagrams-as-code tools make this especially easy, since the diagram is just a small text file that can live right next to the classes it describes, get reviewed in the same way code changes are reviewed, and stay far more likely to be kept up to date as the design evolves.

“Design a parking lot,” “design a library system,” “design a vending machine” — if these sound familiar, it is because LLD-style questions are a favourite in technical interviews, often called “object-oriented design” or “low-level design” rounds.

Interviewers are not hoping for a flawless final answer in thirty minutes. They are watching how a candidate breaks a fuzzy problem into clear classes, whether they notice when one class is quietly doing too much, and whether they can explain their reasoning clearly enough for someone else to follow and challenge. These are the exact same instincts a real LLD depends on, which is why the exercise has become such a durable part of technical hiring.

A good way to prepare is practising on a handful of classic examples — a parking lot, a library system, a vending machine, a chess game — not to memorise a single “correct” answer, but to build comfort with the underlying rhythm: identify the nouns, assign responsibilities, draw relationships, trace a key flow, and think through what could go wrong. That rhythm transfers to almost any new problem an interviewer might invent on the spot.

The “God Class”

A single class that quietly grows to handle far too many responsibilities — validating input, saving data, sending emails, calculating prices — until nobody fully understands everything it does anymore. It becomes the one file everyone is afraid to touch, because a small change might break something completely unrelated hiding inside it.

Designing Classes Around the Database, Not the Problem

It is tempting to make classes mirror database tables exactly. But a class exists to represent a real-world idea and its behaviour, while a table exists to store data efficiently — the two do not always want to be shaped identically, and forcing them to match can produce a design that is technically tidy but genuinely awkward to actually use.

Over-Engineering with Patterns

Reaching for an elaborate design pattern to solve a genuinely simple problem adds layers of indirection that make the code harder, not easier, to follow. A pattern earns its place by solving real complexity — not by making a small feature look more impressive than it needs to be.

Skipping Edge Cases

A design that only considers the smooth, happy path — where every input is valid and nothing ever fails — tends to fall apart the moment reality intrudes. What happens if two customers try to reserve the very last parking spot at the exact same second? A design that never asked that question will discover the answer the hard way, in production.

Designing in Isolation

A class diagram that never gets shown to anyone else misses one of LLD’s biggest benefits — a second set of eyes catching an overlooked responsibility, a missing relationship, or a class trying to do too much. The value of writing it down evaporates if nobody else ever reads it.

Chasing Perfect Flexibility Nobody Needs

It is possible to over-design too, by building layers of configurable flexibility for changes that will realistically never happen. A parking lot system built to theoretically support underwater parking spots is solving a problem nobody has, at the cost of making the everyday, real problem harder to understand. The goal is a design flexible enough for changes that are genuinely likely, not flexible enough for absolutely anything imaginable.

Notice that nearly every pitfall here traces back to the same root habit: rushing past the thinking stage to get to the typing stage. LLD is not about slowing a team down for its own sake — it is about spending a small amount of careful thought up front so that the much larger amount of time spent later, maintaining and extending the code, stays smooth instead of painful.

Unlike HLD, which is often owned by one architect or tech lead, LLD is frequently a team sport — the developers who will actually build a given component are usually the ones best placed to design its classes in detail, since they are the ones who will live with that design daily. A senior engineer might sketch the first draft, but the whole team building that feature typically reviews and refines it together.

LLD sits right after HLD and right before real coding begins, translating an already-approved big picture into a precise, buildable plan for one component at a time. Some teams keep this step fairly lightweight — a quick sketch and a short conversation — for small, well-understood features, while reserving a fuller, written LLD for anything genuinely complex, risky, or destined to be touched by many developers over time. Matching the amount of design effort to the actual complexity of the problem is itself a design skill worth developing.

It is also common for LLD to be revisited in a lightweight “design huddle” — a short, informal conversation among two or three developers before diving into code, rather than a heavyweight formal document every single time. The formality should scale with the stakes: a quick sketch on a shared screen is plenty for a small internal tool, while a payment system touching real money deserves a much more thorough, carefully reviewed write-up.

Here is a short checklist covering what shows up in most solid Low-Level Design write-ups. Treat it as a flexible starting point — a small feature might only need the first few items, while a complex one might need every section filled out in detail. There is no shame in a one-page LLD for a one-page problem; the checklist exists to make sure nothing important was skipped, not to pad out a document for its own sake.

Keep this checklist somewhere handy and treat it the way a careful cook treats a recipe card — not a rulebook to follow blindly, but a reliable reminder of the ingredients that make the final result turn out well.

Do I need to know UML perfectly to write an LLD?

Not at all. Knowing a handful of common symbols — a box for a class, a triangle for inheritance, a diamond for composition — covers the vast majority of real-world diagrams. The goal is clear communication, not a perfect grade on a UML exam.

Is LLD only useful for object-oriented languages?

The class-and-object style of LLD fits object-oriented languages most naturally, but the underlying habit — breaking a problem into clearly responsible, well-connected pieces before writing code — is valuable no matter which language or programming style a team uses.

How detailed should a sequence diagram be?

Detailed enough to answer the real questions a developer would have — who calls whom, in what order, and what happens if a step fails — without trying to capture literally every possible path through the code. If it starts feeling as long as the code itself, it has likely gone further than it needs to.

What is the difference between a design pattern and a design principle?

A principle, like Single Responsibility, is a general habit of good design that applies almost everywhere. A pattern, like Singleton or Observer, is a specific, reusable solution to a specific recurring problem. Principles guide judgment; patterns are tools you reach for when the judgment says they fit.

Can LLD change after coding starts?

Yes, and it often does in small ways. As a developer works through the actual implementation, they sometimes discover a cleaner class boundary or a relationship that was not obvious on paper. That is a healthy, normal part of building software — the original LLD simply gets updated to reflect what was learned.

Do I always need both a class diagram and a sequence diagram?

Not necessarily. A simple feature with one or two classes and a straightforward flow might only need a class diagram, or even just a short written description. Sequence diagrams earn their place when the order of operations across several classes is genuinely tricky to hold in your head — use them when they add clarity, and skip them when they would just add extra pages nobody needs.

What is the single most common mistake beginners make in LLD?

Letting one class grow to do too much, simply because it was the file already open in the editor. It feels faster in the moment, but it is almost always the seed of the “God Class” problem described earlier — a few extra minutes spent asking “whose job is this, really?” pays for itself many times over.

If you remember nothing else from this guide, remember this: Low-Level Design is the small, careful investment that turns rough big-picture plans into code a team can actually build, review, and change with confidence. Every idea in this guide — the classes, the diagrams, the SOLID habits, the patterns, the pitfalls — exists to support that one underlying goal.

Practising LLD is really practising a small, patient habit: pausing long enough to name the classes, assign them one honest job each, draw the relationships that actually matter, and think through the edges before the happy path becomes the only path. That habit rarely feels dramatic while it is happening, but it is quietly what separates the code that keeps its team moving forward from the code that slowly turns into a burden. Every part of this guide has really just been pointing at that one simple, quiet instinct — and it is an instinct anyone can build, one small design at a time.