Understanding Low-Level Design (LLD) in Simple Words — With an Online Shopping App Example

When I first started learning Low-Level Design (LLD), it sounded like a very big and complicated topic.

I used to think it was only for very senior developers or for people working in Java.

But after spending some time on it, I realised the core idea is actually very simple.

LLD is just about planning the small details of how a feature or system will work before we jump into writing full code.

In this post, let’s understand Low-Level Design in very simple words using a relatable example:

an online shopping app like Flipkart.

We will not go too deep into advanced theory.

The goal is just to build a clear beginner-friendly understanding.

---

🧠 What Is Low-Level Design (LLD)?

Low-Level Design means thinking about the detailed structure of a system.

It focuses on questions like:

• what small parts will exist inside the feature
• what each part will do
• how those parts will talk to each other
• what data they will handle
• what should happen step by step

In simple words:

LLD is the stage where your idea starts becoming close to real code.

---

🏠 A Very Simple Real-Life Analogy

Think of building a house.

High-Level Design (HLD)

This is like deciding:

• where the bedroom will be
• where the kitchen will be
• where the bathroom will be

This is the big picture.

Low-Level Design (LLD)

This is like deciding:

• where the switchboard will go
• where the pipes will go
• where the tap will be placed
• what material will be used

So:

• HLD = big picture
• LLD = detailed picture

That is the main difference.

---

🆚 HLD vs LLD in Simple Words

Let’s say we are building an online shopping app.

HLD says:

We need:

• login
• home page
• product page
• cart
• address
• payment

This is the overall structure.

LLD says:

Okay, but now:

• how will login work?
• how will cart store products?
• how will quantity increase?
• how will address be saved?
• what happens if payment fails?
• which part should handle what?

This is Low-Level Design.

So if I say it in one line:

HLD tells us what main parts the system has.

LLD tells us how each part will actually work.

---

🛒 Let’s Understand LLD Using an Online Shopping App

Suppose a user opens an online shopping app.

The flow is something like this:

1. User logs in
2. User goes to home page
3. User selects a product
4. User adds product to cart
5. User changes quantity
6. User adds address
7. User makes payment
8. Order gets placed

At first, this looks like one simple flow.

But in LLD, we break this into smaller parts.

That is where things become clearer.

---

🔍 Step 1: Break the Big Feature Into Small Parts

Instead of saying:

“User buys a product”

LLD says:

Let’s break it into small jobs.

For this shopping app, some small parts can be:

• Login handling
• Product handling
• Cart handling
• Address handling
• Payment handling
• Order handling

Now the system already feels easier to understand.

---

👤 1) Login Part

When the user tries to log in, many small checks can happen.

For example:

• check if email or phone is valid
• check if password is correct
• create user session after successful login
• show error if login fails

So LLD asks:

• who will validate login?
• where will session be created?
• what should happen if password is wrong?

Even one small feature like login has many details inside it.

That is LLD thinking.

---

📦 2) Product Part

Now user comes to the home page and sees products.

Each product may have data like:

• product id
• product name
• price
• stock
• image
• description

Now LLD asks:

• where should product data come from?
• how should one product be shown?
• what happens if item is out of stock?
• what should happen when user opens product details?

So again, we are moving from “show products” to “how exactly should this work?”

---

🛒 3) Cart Part

Now user clicks Add to Cart.

This sounds easy.

But inside it, many small decisions are there.

For example:

• if product is already in cart, increase quantity
• if product is not in cart, add it as a new item
• check stock before increasing quantity
• calculate total price
• remove item if quantity becomes 0

This is a very good LLD example.

Because “cart” is not just one button.

It has real logic behind it.

---

➕ 4) Quantity Part

Suppose user clicks + to increase quantity.

Now LLD asks:

• should quantity increase directly?
• should stock be checked first?
• what if only 2 items are left in stock?
• what if user tries to add 10?

So behind one small + button, there is still some detailed thinking.

That is why LLD is important.

It helps us think before we write messy code.

---

📍 5) Address Part

Before payment, user adds delivery address.

Now again, it is not just “save address”.

There can be many checks:

• name should not be empty
• pin code should be valid
• phone number should be valid
• city and state should be selected properly

And then we also think:

• should user save multiple addresses?
• should there be one default address?
• where should selected address be stored?

These are all LLD-type questions.

---

💳 6) Payment Part

Now user clicks on payment.

This also has many details:

• which payment method is selected?
• is payment successful?
• what if payment fails?
• what if money is deducted but order is not placed?
• when should order status become confirmed?

This is where detailed design becomes very important.

Because payment mistakes can create real problems.

---

📄 7) Order Part

After successful payment, order should be created.

Now LLD asks:

• when exactly should order be created?
• what product details should be saved?
• what address should be attached?
• what payment status should be stored?
• what order status should be shown?

Again, this is not just “place order”.

There is a lot happening inside.

---

🧩 So What Is LLD Really Doing Here?

In this whole shopping app example, LLD is helping us do one simple thing:

break one big user flow into small, clear, manageable parts.

Instead of writing everything in one big file or one huge function, we think in smaller responsibilities.

That makes the system:

• easier to understand
• easier to build
• easier to debug
• easier to extend later

---

⚙️ A Simple Beginner Way to Think About It

You can think of the shopping app like a team of workers.

• one worker handles login
• one worker handles products
• one worker handles cart
• one worker handles address
• one worker handles payment
• one worker handles orders

If one person does everything alone, confusion happens.

Same in code.

That is why we break the feature into small parts.

This is one of the most important ideas in Low-Level Design.

---

💻 A Small Code-Like Example

Let’s say we want to model a very small cart system.

Here is a simple example:

class CartItem {
  constructor(productId, name, price, quantity = 1) {
    this.productId = productId;
    this.name = name;
    this.price = price;
    this.quantity = quantity;
  }

  increaseQuantity() {
    this.quantity++;
  }

  getTotal() {
    return this.price * this.quantity;
  }
}

class Cart {
  constructor() {
    this.items = [];
  }

  addProduct(product) {
    const existingItem = this.items.find(
      (item) => item.productId === product.productId
    );

    if (existingItem) {
      existingItem.increaseQuantity();
    } else {
      this.items.push(new CartItem(product.productId, product.name, product.price));
    }
  }

  getCartTotal() {
    return this.items.reduce((total, item) => total + item.getTotal(), 0);
  }
}

What is happening here?

• CartItem handles one item
• Cart handles the full cart
• addProduct() decides whether to add new item or increase quantity
• getCartTotal() calculates total

This is a very small example, but it shows the idea well.

We are separating responsibilities clearly.

That is the heart of LLD.

---

📌 Why LLD Matters

Low-Level Design is useful because it helps us:

1. Avoid messy code

If we start coding without thinking, one file or one function can become too big.

2. Improve clarity

When each part has one clear job, the project becomes easier to understand.

3. Make features easier to extend

Later, if you want to add coupon logic, wishlist, or order tracking, a better design helps a lot.

4. Work better in teams

When the structure is clear, different developers can work on different parts more easily.

5. Build stronger interview thinking

Many companies ask LLD not because they only want syntax, but because they want to see how you think.

---

🎯 Important Point: LLD Is Not Just About Classes

This is something beginners should understand clearly.

LLD does not mean:

“Just create some classes.”

LLD is bigger than that.

It means:

• thinking clearly
• dividing work properly
• deciding responsibilities
• designing the flow before coding

Classes can be one part of it.

But the bigger idea is clean planning.

---

🚀 Final Thoughts

When I first started learning Low-Level Design, I thought it was something very advanced.

But after understanding it better, I realised the idea is actually simple:

• take one big feature
• break it into small parts
• decide what each part should do
• think about the step-by-step flow before coding

That is Low-Level Design.

If you are a beginner, do not worry about making it perfect from day one.

Just start with simple examples like:

• login system
• shopping cart
• food delivery app
• movie booking app

Once you practice breaking features into smaller responsibilities, LLD starts making much more sense.

And honestly, this is one of those topics that sounds scary at first, but becomes much easier when you connect it to real product flows.

---

🙋‍♂️ About Me

Hi, I’m Saurav Kumar.

I enjoy learning, building, and writing about web development in simple words—especially breaking down topics that are useful for beginners and developers preparing for interviews.

Right now, I’m focusing on deepening my understanding of core concepts like JavaScript, Object-Oriented Programming, system design, and software engineering fundamentals.

Let's connect!

🐙 GitHub: @saurav02022
💼 LinkedIn: Saurav Kumar