When preparing for Software Engineering/System Design interviews, you'll often encounter two common design rounds: High-Level Design (HLD) and Low-Level Design (LLD).
Although both evaluate your design skills, they focus on different levels of abstraction.
High-Level Design (HLD) focuses on the overall architecture of a system. It covers the major components, their responsibilities, how they communicate, scalability, reliability, and other system-wide design decisions.
Low-Level Design (LLD) focuses on the implementation details of individual components. It deals with classes, objects, interfaces, design patterns, relationships, business logic, and the internal structure of the code.
A simple way to understand the difference is:
HLD answers: "What components does the system need, and how do they interact?"
LLD answers: "How should each component be designed and implemented?"
What is LLD: Low Level Design
Low-Level Design (LLD) is the phase of system design that focuses on how individual components of a system are built internally as opposed to High-Level Design (HLD), which focuses on the overall architecture and what components exist and how they interact at a broad level.
Example
If HLD says "we need a Ride-Booking Service" for something like Uber, LLD would define:
Classes:
Ride,Driver,Rider,Trip,PaymentHandlerMethods:
Ride.assignDriver(),Trip.calculateFare()Design pattern: maybe a Strategy pattern for different fare calculation types (surge pricing, flat rate)
Database tables:
rides,drivers,paymentswith exact columnsSequence diagram: showing the exact call order when a rider requests a ride
Phase 1 : OOP Foundations
OOP (Object-Oriented Programming) is a programming paradigm that organizes code around objects bundles of data (attributes) and behavior (methods) rather than around functions and logic operating on raw data separately (as in procedural programming).
Core Elements
1. Classes & Objects
Before diving into the pillars, it helps to understand the foundational components of OOP:
Class: A blueprint or template that defines the properties (data) and behaviors (methods) an object will have. (Think of this as the architectural plan for a house.)
Object: A specific instance of a class that takes up actual memory. (Think of this as the actual house built from the plan.
2. Constructors
A constructor is a special method that is automatically invoked when an object is created. Its primary purpose is to initialize the object's state by assigning values to its fields or performing any required setup. Unlike regular methods, a constructor has the same name as the class and does not have a return type.
Why do we need constructors?
Initialize object fields.
Ensure every object starts in a valid state.
Reduce repetitive initialization code.
Example: When creating a Car object, the constructor can initialize its brand, model, and color.
3. Encapsulation
Encapsulation is the process of combining data (fields) and the methods that operate on that data into a single unit (class) while restricting direct access to the data using access modifiers. Instead of allowing other classes to modify data directly, encapsulation provides controlled access through methods such as getters and setters.
Benefits:
Protects data from unauthorized access.
Improves maintainability.
Makes the code easier to modify without affecting other components.
Enforces business rules before updating data.
Example: A BankAccount class keeps its balance private and only allows updates through deposit() and withdraw() methods.
4. Abstraction
Abstraction is the process of hiding complex implementation details and exposing only the essential functionality required by the user. It allows users to interact with an object without knowing how it works internally. In Java, abstraction is achieved using abstract classes and interfaces.
Benefits:
Reduces complexity.
Improves security by hiding implementation details.
Makes code easier to maintain and extend.
Example: You can drive a car using the steering wheel and pedals without understanding how the engine works internally.
5. Inheritance
Inheritance allows a class (child class) to inherit the properties and behaviors of another class (parent class). It promotes code reuse and establishes an "is-a" relationship. The child class can reuse existing functionality and add new features or override existing behavior.
Benefits:
Reduces code duplication.
Improves reusability.
Makes applications easier to extend.
Example: A Car class inherits common properties such as brand and speed from a Vehicle class.
6. Polymorphism
Polymorphism means "many forms." It allows the same method or interface to behave differently depending on the object that invokes it. There are two types:
Compile-time Polymorphism (Method Overloading)
Runtime Polymorphism (Method Overriding)
Benefits:
Improves flexibility.
Reduces conditional logic.
Makes code easier to extend.
Example: A draw() method behaves differently for Circle, Rectangle, and Triangle.
7. Interfaces
An interface defines a contract that specifies what a class must do without specifying how it should do it. Any class implementing an interface must provide implementations for all of its methods. Interfaces enable multiple unrelated classes to follow the same contract while having different implementations.
Benefits:
Supports abstraction.
Encourages loose coupling.
Makes systems easier to test and extend.
Example: A Payment interface can be implemented by CreditCardPayment, UPIPayment, and PayPalPayment, where each class processes payments differently.
8. Association
Association represents a relationship between two independent objects where each object has its own lifecycle. Neither object owns the other; they simply interact or collaborate. Association can be:
One-to-One
One-to-Many
Many-to-One
Many-to-Many
Example: A Teacher teaches multiple Students, but both can exist independently.
9. Aggregation
Aggregation is a specialized form of association that represents a weak "has-a" relationship. One object contains another object, but the contained object can exist independently even if the parent object is destroyed.
Benefits:
Promotes object reuse.
Maintains independent object lifecycles.
Example: A Department has multiple Employees. If the department is deleted, the employees continue to exist.
10. Composition
Composition is a strong "has-a" relationship where the child object's lifecycle depends entirely on the parent object. If the parent object is destroyed, the child objects are destroyed as well. Composition represents ownership and is stronger than aggregation.
Benefits:
Provides strong ownership.
Improves encapsulation.
Models real-world part-of relationships effectively.
Example: A House consists of multiple Rooms. If the house is demolished, the rooms no longer exist independently.
Understand Through Interactive Explorer
Object-Oriented Programming can feel abstract when you're just reading definitions, so here's a hands-on way to explore it instead. The interactive explorer below walks through all nine core OOP concepts from constructors to composition, using simple Java examples and everyday analogies for each one. Click through the concepts at your own pace, then test what you've learned with the built-in quiz at the end.
Phase 2: UML and Object Modeling
What is Object Modeling?
Object Modeling is the process of representing a real-world problem as software objects.Instead of thinking about functions or database tables first, we think about:
What objects exist?
What information do they have?
What actions can they perform?
How do they interact?
In other words,
Object Modeling is the blueprint of an object-oriented software system.
What is UML?
UML (Unified Modeling Language) is a standard visual language used to model, design, and document software systems. It is not a programming language. You cannot execute UML diagrams. They are used to communicate and visualize a system's design.
Think of UML as the language of software blueprints, just as architects use architectural drawings before constructing a building.
Why is UML Needed?
Suppose a team has 20 developers, 5 testers, 3 architects, 2 product managers. Instead of explaining the system verbally, everyone can understand the same UML diagrams.
UML helps teams:
Visualize the system
Reduce misunderstandings
Plan before coding
Document architecture
Quick Visual Recap
Types of UML Diagrams
1. Class Diagram
A Class Diagram is a UML Structural Diagram that represents the static structure of a software system. It shows:
Classes
Attributes (data)
Methods (behavior)
Relationships between classes
It is called a static diagram because it describes what the system looks like, not how it behaves over time.
Definition: A Class Diagram is a blueprint of your application's classes and the relationships among them before you start coding.
Structure of a Class
+--------------------------------+
| User | ----> Class Name
+--------------------------------+
| - id : int |
| - name : String | ----> Attributes
| - email : String |
+--------------------------------+
| + login() : boolean |
| + logout() : void | ----> Methods
| + updateProfile() : void |
+--------------------------------+
-----------Equivalent Python----------
class User:
def __init__(self, user_id: int, name: str, email: str):
self.id = user_id
self.name = name
self.email = email
def login(self) -> bool:
return True
def logout(self) -> None:
pass
def update_profile(self) -> None:
passVisibility Symbols
Symbol | Meaning | Java Equivalent |
|---|---|---|
+ | Public | public |
- | Private | private |
# | Protected | protected |
~ | Package | default |
Relationships in Class Diagrams
The six major relationships are:
Association: Two objects know each other.
Customer ------ OrderAggregation: A weak HAS-A relationship.
Department ◇──── EmployeeComposition: A strong HAS-A relationship.
House ◆──── RoomInheritance (Generalization): An IS-A relationship.
Dog --------▷ AnimalRealization: Used for Interfaces.
CreditCard - - -▷ PaymentDependency:
OrderService ------> PaymentGatewayThese relationships help model the real-world interactions between objects.
Example Class Diagram
+----------------------+
| Student |
+----------------------+
| - id |
| - name |
+----------------------+
| + enroll() |
| + dropCourse() |
+----------------------+
|
| enrolls
|
*
+----------------------+
| Course |
+----------------------+
| - code |
| - title |
+----------------------+
| + addStudent() |
+----------------------+This diagram tells us:
StudentandCourseare separate classes.A
Studenthas data (id,name) and behavior (enroll(),dropCourse()).A
Coursehas its own attributes and methods.One student can enroll in multiple courses (indicated by
*).
Quick Visual Recap
2. Object Diagram
An Object Diagram is a UML Structural Diagram that represents the instances (objects) of classes and the relationships between those objects at a particular point in time.
Unlike a Class Diagram, which defines the structure of classes, an Object Diagram shows:
Real objects
Current attribute values
Links between objects
Definition: An Object Diagram is a snapshot of a system that illustrates specific objects, their attribute values, and their relationships at a given moment.
Why Do We Need an Object Diagram?
Suppose you've designed a Library Management System.
Your Class Diagram defines:
Book
Member
Librarian
However, it doesn't tell you:
Which member borrowed which book?
What are the actual values of object attributes?
How are the objects connected at runtime?
An Object Diagram answers these questions.
Why is it Called an Object Diagram?
Because it represents objects, not classes.
Example:
Class Diagram
StudentObject Diagram
student1 : Student
student2 : StudentNotice the difference.
The Object Diagram uses instances.
Components of an Object Diagram
1. Object: An object is an instance of a class.
Notation
student1 : StudentMeaning
Object Name
student1Class
Student2. Attribute Values: Unlike Class Diagrams, object Diagrams store actual values.
Example
+------------------------+
| student1 : Student |
+------------------------+
| id = 101 |
| name = "Ritesh" |
+------------------------+Notice that the datatype is replaced by actual data.
3. Links: Links connect objects.
Example
student1 -------- course1Meaning
Student 1 is enrolled in Course 1. Links represent runtime relationships.
Example : Student Management System
Suppose we have:
Classes
Student
CourseObjects
student1
course1Object Diagram
+-----------------------+
| student1 : Student |
+-----------------------+
| id = 101 |
| name = "Ritesh" |
+-----------------------+
|
| enrolledIn
|
+-----------------------+
| course1 : Course |
+-----------------------+
| code = CS101 |
| title = Java |
+-----------------------+This diagram tells us:
Student 101 exists.
His name is Ritesh.
He is enrolled in Java.
A Class Diagram cannot show these actual values.
Quick Visual Recap
3. Sequence Diagram
A Sequence Diagram is a UML Behavioral Diagram that illustrates the order of interactions (messages) exchanged between objects or components over time to accomplish a particular use case. It answers questions like:
What happens when a user logs in?
Which object calls which method?
In what order are methods executed?
What is the flow of control?
What response is returned at each step?
Definition: A Sequence Diagram models the chronological sequence of messages exchanged between objects during the execution of a scenario.
Why Do We Need a Sequence Diagram?
Suppose you're building an e-commerce application. A user clicks "Place Order." Many things happen behind the scenes:
User is authenticated.
Cart items are fetched.
Inventory is checked.
Payment is processed.
Order is created.
Notification is sent.
A Class Diagram tells you these classes exist, but it doesn't explain which one talks first. A Sequence Diagram shows the complete interaction.
When Should You Use a Sequence Diagram?
Use a Sequence Diagram when you want to model:
User Login
Registration
Checkout
Payment Flow
File Upload
Password Reset
Order Placement
OTP Verification
API Request Flow
Microservice Communication
In general, any workflow involving multiple objects is a good candidate.
Components of a Sequence Diagram:
1. Actor: An Actor represents an external entity that interacts with the system.
Examples:
Customer
Admin
User
Payment Gateway
Delivery Partner
👤 UserThe actor always initiates the interaction.
2. Objects (Participants): Objects represent the classes or services participating in the interaction.
User
LoginController
AuthService
UserRepository
DatabaseThese participants are arranged left to right across the top of the diagram.
3. Lifeline: A Lifeline shows the existence of an object during the interaction. It is represented by a vertical dashed line.
User LoginController
| |
| |
| |
| |Time flows from top to bottom.
4. Activation Bar: The Activation Bar (also called the execution specification) indicates the period during which an object is actively executing an operation.
Controller
|
|█████
|█████
|It shows that the object is processing a request.
5. Messages: Messages represent communication between participants.
Synchronous Message: The sender waits for the receiver to finish.
Controller ---------> ServiceExample:
service.login();The controller cannot continue until login() returns.
Asynchronous Message: The sender does not wait.
NotificationService -----> EmailQueueExample:
sendEmailAsync();The application continues processing while the email is sent in the background.
Combined Fragments
Sequence Diagrams can represent conditions, loops, and parallel execution using combined fragments.
1. alt (Alternative)
Represents an if-else condition.
+-----------------------------+
| alt |
|-----------------------------|
| Valid Password |
| Generate Token |
|-----------------------------|
| Invalid Password |
| Return Error |
+-----------------------------+
---------------Equivalent Python code-------------
if password_correct:
generate_token()
else:
return error2. opt (Optional)
Represents an optional operation.
+-----------------------------+
| opt Remember Me |
|-----------------------------|
| Store Cookie |
+-----------------------------+
---------------Equivalent Python code-------------
if remember_me:
store_cookie()3. loop(Iterations)
Represents repeated execution.
+---------------------------+
| loop For Each Product |
|---------------------------|
| Check Inventory |
+---------------------------+
---------------Equivalent Python code-------------
for product in cart:
check_inventory(product)4. par
Represents parallel execution.
+------------------------------+
| par |
|------------------------------|
| Send Email |
|------------------------------|
| Send SMS |
+------------------------------+Both tasks execute simultaneously.
Example: User Login Flow
User LoginController AuthService UserRepository Database
| | | | |
|----login()------>| | | |
| |----authenticate()-> | |
| | |----findUser()--->| |
| | | |----SELECT---->|
| | | |<---User-------|
| | |<---User----------| |
| |<---JWT Token-----| | |
|<---Success-------| | | |Quick Visual Recap
4. Use Case Diagram
A Use Case Diagram is a UML Behavioral Diagram that illustrates the functional requirements of a system by showing:
Actors (who interacts with the system)
Use Cases (what the system does)
Relationships between actors and use cases
The boundary of the system
It focuses on user goals rather than classes, methods, or algorithms.
Definition: A Use Case Diagram visually represents the interactions between external actors and the system to achieve specific business goals.
Why Do We Need a Use Case Diagram?
Suppose you're building an Online Shopping System. Before designing classes or writing code, you need to understand:
Who will use the system?
What actions can they perform?
Which features should the system provide?
A Use Case Diagram answers these questions. Without one, developers may misunderstand the requirements, resulting in missing or unnecessary features.
When Should You Use a Use Case Diagram?
Use a Use Case Diagram during:
Requirements gathering
Business analysis
Software planning
Client discussions
Feature identification
Project documentation
It is usually one of the first UML diagrams created because it helps define what the system should do before deciding how it will do it.
Components of a Use Case Diagram
1. Actor
An Actor is any external entity that interacts with the system. An actor is not part of the system.
Actors can be:
Human users
External systems
Hardware devices
Third-party services
O
/|\
/ \
Customer2. Use Case
A Use Case represents a function or service provided by the system.
Examples:
Login
Register
Search Products
Add to Cart
Place Order
Make Payment
Track Order
Notation:
( Place Order )Each use case represents a complete user goal.
3. System Boundary
The System Boundary defines the scope of the system. Everything inside the boundary belongs to the system. Everything outside represents external actors.
Example:
+------------------------------------------+
| Online Shopping System |
| |
| (Login) |
| (Search Products) |
| (Add to Cart) |
| (Checkout) |
| |
+------------------------------------------+
CustomerThis clearly separates the system from its environment.
4. Association
Association represents communication between an actor and a use case.
Example:
Customer -------- (Place Order)Meaning:
The customer can place an order.
Association is represented using a simple solid line.
5. <<include>> Relationship
Sometimes one use case always requires another use case. Instead of repeating the same functionality, UML uses <<include>>.
Example:
When placing an order:
Validate Cart
Calculate Total
Process Payment
These steps are mandatory.
Diagram:
(Place Order)
|
<<include>>
|
(Process Payment)Meaning:
Every time "Place Order" executes, "Process Payment" must also execute.
6. <<extend>> Relationship
Sometimes additional functionality is optional. In that case, UML uses <<extend>>.
Example:
After placing an order, the customer may purchase gift wrapping.
Diagram:
(Gift Wrap)
^
|
<<extend>>
|
(Place Order)Gift wrapping is optional. The order can still be placed without it.
7. Generalization
Generalization represents inheritance between actors or use cases.
Example:
User
▲
┌─────┴─────┐
│ │
Customer AdminBoth Customer and Admin inherit common behaviors from User.
Example: Food Delivery System
Customer
|
------------------------------------
| | | |
| | | |
(Login) (Browse Menu) (Place Order) (Track Order)
|
<<include>>
|
(Process Payment)
|
<<include>>
|
(Generate Invoice)
^
|
<<extend>>
|
(Apply Coupon)Quick Visual Recap
5. State Diagram
A State Diagram is a UML Behavioral Diagram that models the different states of an object and the transitions between those states based on events.
It answers questions like:
What happens after an order is placed?
When does a payment become successful?
How does a ticket move from "Open" to "Closed"?
What are all the possible states of a user account?
Definition: A State Diagram represents the lifecycle of an object by showing its states, the events that trigger state changes, and the transitions between those states.
Why Do We Need a State Diagram?
Suppose you're building an E-Commerce System. An order doesn't remain the same forever. It moves through several stages:
Created
↓
Confirmed
↓
Packed
↓
Shipped
↓
DeliveredSometimes things don't go as planned:
Created
↓
Cancelledor
Shipped
↓
ReturnedA State Diagram helps developers understand every possible state and transition, ensuring that invalid transitions (such as shipping a cancelled order) are prevented.
When Should You Use a State Diagram?
State Diagrams are useful whenever an object has a lifecycle.
Common examples include:
Order Processing
User Account Status
ATM Machine
Elevator System
Traffic Light
Online Payment
Flight Booking
Support Ticket
Food Delivery
Document Approval Workflow
If an object changes state over time, a State Diagram is often the right choice.
Components of a State Diagram
1. Initial State: The Initial State represents where the object's lifecycle begins.
Notation:
●Example:
●
|
v
CreatedEvery State Diagram typically has one initial state.
2. State: A State represents a condition or situation during the object's lifetime.
Examples:
Created
Pending
Approved
Rejected
Active
Suspended
Notation:
+------------------+
| Pending |
+------------------+An object performs certain behavior while it remains in that state.
3. Transition: A Transition represents movement from one state to another.
Notation:
Pending --------> ApprovedA transition occurs when an event happens.
4. Event: An Event triggers a transition.
Example:
Pending ----approve()----> ApprovedHere, approve() is the event.
Other examples:
pay()
cancel()
ship()
deliver()
login()
5. Guard Condition: Sometimes a transition occurs only if a condition is true.
Notation:
Pending --[Payment Successful]--> ConfirmedThe transition happens only when payment succeeds.
Python equivalent:
if paymentSuccessful:
state = CONFIRMED6. Action: A transition may execute an action.
Example:
Pending
|
approve()
/sendEmail()
|
▼
ApprovedWhen approval occurs, an email is sent.
7. Final State: The Final State indicates the end of the object's lifecycle.
Notation:
◎Example:
Delivered
|
▼
◎Once the object reaches the final state, no further transitions occur.
Example: User Account Lifecycle
●
|
▼
+--------------+
| Registered |
+--------------+
|
verifyEmail()
|
▼
+--------------+
| Active |
+--------------+
/ \
suspend() deactivate()
| |
▼ ▼
+-------------+ +-------------+
| Suspended | | Deactivated |
+-------------+ +-------------+
|
▼
◎Quick Visual Recap
6. Activity Diagram
An Activity Diagram is a UML Behavioral Diagram that represents the flow of activities in a system, showing how a process starts, executes, makes decisions, runs tasks in parallel, and eventually ends.
It answers questions like:
What steps are involved in placing an order?
How does a loan approval process work?
What happens after a user logs in?
Which activities can run simultaneously?
Where are the decision points?
Definition: An Activity Diagram models the workflow of a business process or system by showing the sequence of activities, control flow, decisions, loops, and parallel execution.
Why Do We Need an Activity Diagram?
Suppose you're designing an Online Shopping System.
When a customer places an order, the system performs several tasks:
Validate the cart
Calculate the total amount
Process payment
Update inventory
Generate invoice
Send confirmation email
Some tasks happen one after another, while others can happen simultaneously. An Activity Diagram provides a clear visualization of this entire workflow.
Real-World Analogy
Imagine making a cup of coffee.
Start
↓
Boil Water
↓
Add Coffee Powder
↓
Add Sugar
↓
Pour Milk
↓
Stir
↓
Serve
↓
EndEach step is an activity, and together they form a complete workflow. An Activity Diagram models business processes in exactly the same way.
When Should You Use an Activity Diagram?
Use an Activity Diagram whenever you need to model a workflow.
Common examples include:
User Registration
Login Process
Checkout Workflow
Food Delivery
ATM Withdrawal
Loan Approval
Hospital Patient Admission
Employee Leave Approval
Online Ticket Booking
CI/CD Deployment Pipeline
If you're modeling a sequence of business activities, an Activity Diagram is usually the best choice.
Components of an Activity Diagram
1. Initial Node: The Initial Node represents the starting point of the workflow.
Notation:
●Example:
●
|
v
LoginEvery Activity Diagram typically has one initial node.
2. Activity: An Activity represents a task or operation.
Examples:
Login
Validate Payment
Search Products
Generate Invoice
Deliver Package
Notation:
+----------------------+
| Process Payment |
+----------------------+Activities are the building blocks of the workflow.
3. Control Flow: A Control Flow arrow connects one activity to the next.
Example:
Login
|
v
Validate UserIt indicates the order in which activities are executed.
4. Decision Node: A Decision Node represents a branching point based on a condition.
Notation:
◇Example:
Validate Payment
|
v
◇
/ \
Success Failure
| |
Ship Order Show Error5. Merge Node: A Merge Node combines multiple alternative paths back into a single flow.
Example:
Success ----\
\
◇
/
Failure ----/
|
v
Generate ReportUnlike a Join Node, a Merge Node does not synchronize parallel tasks—it simply reunites alternative branches.
6. Fork Node: A Fork Node starts multiple activities in parallel.
Notation:
==========Example:
Process Payment
|
v
==========
| |
v v
Send Email
Update InventoryBoth activities start at the same time.
7. Join Node: A Join Node synchronizes parallel activities.
Example:
Send Email -------\
\
==========
/
Update Inventory--/
|
v
Complete OrderThe workflow continues only after both parallel activities have finished.
8. Final Node: The Final Node indicates the end of the workflow.
Notation:
◎Example:
Deliver Order
|
v
◎9. Swimlanes (Optional): Swimlanes divide the workflow based on responsibility.
Example:
+-----------+-------------------+------------------+
| Customer | Order Service | Payment Gateway |
+-----------+-------------------+------------------+
| Login | | |
| Place | Create Order | |
| Order |------------------>| Process Payment |
| |<------------------| Payment Success |
+-----------+-------------------+------------------+Swimlanes help identify who is responsible for each activity.
Example: Online Shopping Workflow
●
|
v
Browse Products
|
v
Add to Cart
|
v
Checkout
|
v
Process Payment
|
v
◇
/ \
Payment Success Payment Failed
| |
v v
Generate Invoice Show Error
|
v
==========
| |
v v
Send Email
Update Inventory
| |
==========
|
v
Ship Order
|
v
◎Workflow Explanation
1. Customer browses products.
2. Adds items to the cart.
3. Checks out.
4. Payment is processed.
5. If payment fails, an error is displayed.
6. If payment succeeds:
a. Invoice is generated.
b. Email is sent.
c. Inventory is updated.
7. Order is shipped.
8. Process ends.Quick Visual Recap
