When you start learning Low Level Design, the hardest part is not writing code.
It is figuring out how to think about the system before writing anything.
Most beginners struggle because they try to jump directly into:
- classes
- methods
- APIs
But real design starts much earlier.
It starts with learning how to see the system correctly and then move through it in a structured way.
This post combines two essential ideas:
- Abstraction & Decomposition (how to see a system)
- Design Thinking Process (how to solve a system step-by-step)
1. The real problem in system design
When given a problem like:
Design a food delivery system
Most people feel stuck because:
- the system feels too large
- everything looks connected
- nothing feels “startable”
This is not a coding problem.
It is a thinking problem.
And the solution is not more knowledge—it is better structure in thinking.
2. Abstraction — learning what to ignore
Abstraction means:
Focus only on what matters, ignore everything else for now.
When you look at a system, you are NOT supposed to see:
- database tables
- API endpoints
- code structure
Instead, you should see:
- what exists in the system
- what roles exist
- what responsibilities exist
Example: Food delivery system
At a high level:
- User places orders
- Restaurant prepares food
- Delivery partner delivers
- System coordinates everything
You are not designing yet.
You are just removing noise.
Why abstraction is important
Without abstraction:
- you try to design everything at once
- you get overwhelmed
- you jump into implementation too early
With abstraction:
- system becomes readable
- complexity becomes manageable
- structure starts appearing naturally
3. Decomposition — breaking the system apart
Once you can see the system clearly, the next step is:
Break it into meaningful parts.
This is decomposition.
Example breakdown
Instead of one “food delivery system”, think in modules:
- User Management
- Restaurant Management
- Order Management
- Payment System
- Delivery System
Now the system is no longer one large problem.
It is a set of smaller problems.
Key insight
Decomposition is NOT coding.
It is:
grouping responsibilities logically
Actors vs Components (important distinction)
A common confusion:
Actors (external)
- User
- Restaurant
- Delivery partner
Components (internal system design)
- Order Service
- Payment Service
- Notification Service
Actors use the system.
Components build the system.
4. The missing link — from thinking to solving
So far, we have:
- Abstraction → how to see the system
- Decomposition → how to break it into parts
But one question remains:
In what order do we actually solve the problem?
That’s where the design process comes in.
5. Design Thinking Process — a structured flow
Instead of randomly designing classes, you follow a sequence.
Step 1: Understand the problem
- What are we building?
- Who are the users?
- What is the goal?
If this is unclear, nothing else matters.
Step 2: Clarify requirements
Split into:
- Functional requirements (what system should do)
- Non-functional requirements (how well it should work)
This prevents wrong assumptions.
Step 3: Identify entities
Look for core concepts in the system.
Example (Parking system):
- ParkingLot
- Slot
- Vehicle
- Ticket
These are NOT classes yet.
They are just building blocks.
Step 4: Define interactions
Now define flow:
- Vehicle enters
- Slot is assigned
- Ticket is generated
- Payment happens on exit
This is the behavior layer.
Step 5: Decompose into components
Now group responsibilities:
- Slot Management
- Ticket Management
- Payment System
This connects abstraction with structure.
Step 6: Refine the design
Only now do you go deeper:
- responsibilities inside each component
- edge cases
- interactions between modules
This is where LLD becomes real.
6. How both ideas connect
Now we unify everything:
| Concept | Purpose |
|---|---|
| Abstraction | Understand what exists |
| Decomposition | Break system into parts |
| Design Process | Decide how to proceed step-by-step |
Mental model
A complete flow looks like this:
- Remove noise (abstraction)
- Identify parts (decomposition)
- Follow sequence (design process)
That’s it.
7. Why this matters in interviews
Most candidates fail not because they lack knowledge, but because:
- they start coding too early
- they miss structure
- they jump between levels of thinking
This framework fixes that.
8. Closing thought
Good system design is not about complexity.
It is about clarity.
If you can:
- see the system clearly
- break it into parts
- and solve it step-by-step
then even complex problems become manageable.
Top comments (0)