HIGH-LEVEL

DESIGN (HLD) System Design

AND LOW-LEVEL Concepts

DESIGN (LLD)
HIGH-LEVEL DESIGN
(HLD)
High Level Design (HLD) is the architectural design
of a system.
It represents the big picture of the overall system –
how different modules will interact, what technologies
will be used, and how the data will flow through the
system.
HLD is the overall system architecture design.
Focuses on 'what' the system will do, not 'how'.
It gives a bird’s eye view of the system.
CHARACTERISTICS OF
HLD
1. System Architecture – Defines components,
modules, and interactions.
2. Technology Stack – Specifies frameworks,
languages, databases, tools.
3. Data Flow – Describes movement of data across
modules.
4. Integration Points – Explains external systems and
APIs.
5. Scalability & Performance – Defines strategies for
scaling and performance.
ABSTRACT VIEW (BIG
PICTURE)
HLD does not go into detail like classes or methods.
It just shows the overall structure of the system.

Example: An e-commerce system has modules like

User, Product, Cart, Payment – but we don’t talk about
methods yet.
 MODULARIZATION OF
SYSTEM

•It divides the system into major modules /

components.
•Each module has a specific responsibility.
•Example: Payment Service handles all
payments, Product Service handles product
listing.
TECHNOLOGY STACK
DEFINITION

•HLD defines which technologies, frameworks,

and databases will be used.
•Example:
• Frontend → React,
• Backend → [Link],
• Database → MongoDB,
• Payment Gateway → Stripe.
DATA FLOW
REPRESENTATION
HLD explains how data moves inside the system.
Example: User request → API Gateway → Backend →
Database → Response back to user.
Often represented using Data Flow Diagrams (DFD).
INTEGRATION WITH
EXTERNAL SYSTEMS
Defines which third-party APIs or services are
connected.
Example: Google OAuth for login, Razorpay for
payments, AWS S3 for file storage.
FOCUS ON SCALABILITY
AND PERFORMANCE

•While designing HLD, we also think about how the system will
handle more users in the future.
Example: Using Load Balancer, Caching (Redis),
Database Sharding.
SECURITY
CONSIDERATIONS
HLD also mentions security at a high level.
Example: Authentication via JWT, HTTPS for secure
communication, Role-based access control.
NON-FUNCTIONAL
REQUIREMENTS (NFRS)
HLD also covers important NFRs like:
Availability (system always accessible)
Reliability (no data loss)
Maintainability (easy to update)
Performance (fast response time).
OUTPUT OF HLD
HLD mainly produces diagrams and documents like:
System Architecture Diagram (block diagram)
Data Flow Diagram
Tech Stack Specification
EXAMPLE (E-
COMMERCE APP HLD)
•Modules:
•User Service
•Product Service
•Cart Service
•Order Service
•Payment Service
•Tech Stack:
•Frontend → React
•Backend → [Link] (Express)
•Database → MongoDB
•External Services → Stripe, AWS S3
LOW LEVEL DESIGN
(LLD)
Low Level Design (LLD) is the detailed blueprint of a
system.
It explains how each module defined in the HLD will
actually work internally.
CHARACTERISTICS OF
LLD
1. Class Diagrams – Defines classes, attributes, and
methods.
2. Database Design – Detailed schema, tables,
relationships.
3. Algorithm Design – Step-by-step process for logic.
4. Interfaces – API contracts, input-output details.
5. Error Handling – Exception management and
recovery strategies.
DETAILED VIEW OF
SYSTEM
Unlike HLD (abstract), LLD provides detailed designs.
Example: If HLD says “There is a Cart Service”, then
LLD will define → classes like Cart, CartItem, methods
like addIitem(), removeItem(), and the database
schema.
CLASS DIAGRAMS
LLD often includes UML class diagrams showing:
•Classes
•Attributes (variables)
•Methods (functions)
•Relationships between classes (inheritance,
composition).
DATABASE SCHEMA
DESIGN

Tables, columns, datatypes, primary keys, foreign keys.

API CONTRACTS
(ENDPOINTS)
Every service’s API endpoints are defined in LLD.
ALGORITHMS & LOGIC
Defines the internal logic or algorithms used.
Example: Search algorithm, Recommendation
algorithm, Payment validation.
ERROR HANDLING &
EDGE CASES

•How the system will behave in unusual situations.

•Example: What if product is out of stock? What if payment fails?
REUSABILITY OF
COMPONENTS
LLD ensures that components are modular and
reusable.
Example: A User Authentication class can be reused in
multiple modules (Orders, Cart, Payment).
INPUT/OUTPUT
SPECIFICATIONS
Defines exactly what input the system will take and
what output it will produce.
OUTPUT OF LLD
LLD mainly produces:
•Class diagrams
•Database schema
•API specifications
•Pseudo-code / algorithms
MONOLITHIC
ARCHITECTURE
Monolithic architecture is a software design methodology
that combines all of an application's components into a
single, inseparable unit. Under this architecture, the user
interface, business logic, and data access layers are all
created, put into use, and maintained as one, unified unit.
It means:
User Interface (UI),
Business Logic,d
Data Access Layer,
Database,
all exist in one big codebase and are deployed as one
executable/application.
THE THREE LAYERS OF
MONOLITHIC
ARCHITECTURE
Presentation Layer (UI Layer)
Business Logic Layer (Application Layer)
Data Access Layer (Persistence Layer)
PRESENTATION LAYER
(UI LAYER)
What it is:
The front-end of the application – what the user
directly interacts with.
Responsibilities:
 Takes input from the user (forms, clicks, actions).
 Displays output (pages, dashboards, results).

Technologies:
 Web → HTML, CSS, JavaScript, React, Angular, Vue
 Mobile → Android (Java/Kotlin), iOS (Swift)

Example:
In an E-commerce App, when a user searches for a
product, the UI shows the search box and displays
results.
BUSINESS LOGIC LAYER
(APPLICATION LAYER)
•What it is:
The brain of the application – where all the rules, processes, and
• decision-making happen.
•Responsibilities:
•Processes user requests.
•Implements business rules (e.g., discounts, taxes, authentication).
•Coordinates between UI and Database.
•Technologies:
•Backend frameworks: [Link] (Express), Java (Spring),
•Python (Django/Flask), .NET, PHP.
•Example:
In an E-commerce App, when the user clicks Buy Now, this layer checks:
•Is the product in stock?
•Is the payment valid?
•Should a discount be applied?
Then it updates the order details before sending back a response.
DATA ACCESS LAYER
(PERSISTENCE LAYER)
•What it is:
The part of the application that talks to the database.
•Responsibilities:
•Connects to the database.
•Runs SQL queries (INSERT, UPDATE, SELECT, DELETE).
•Ensures data consistency and security.
•Technologies:
•SQL Databases: MySQL, PostgreSQL, Oracle.
•NoSQL Databases: MongoDB, Cassandra.
•ORMs (Object Relational Mappers): Hibernate (Java),
• Sequelize ([Link]), Mongoose (MongoDB).
•Example:
In an E-commerce App, when the order is confirmed, this layer saves order
• details into the Orders table and updates the Inventory table in the database.
CHARACTERISTICS

•Single Codebase – Whole app in one repository.

•Single Deployment Unit – One build, one deploy.
•Shared Database – Centralized DB for all modules.
•Tightly Coupled – All modules depend on each other.
•Synchronous Communication – Internal method calls
(no network overhead).
MICROSERVICES
ARCHITECTURE
Microservices is an architectural approach to designing software
systems where an application is divided into small, independent
services.
Each service focuses on one business function.
All services together make the complete system.
They communicate with each other using APIs or message queues.
Think of it like a company:
HR Department → Manages employees
Finance Department → Handles payments and salaries
Sales Department → Deals with customers
Support Department → Handles complaints
Each department is independent, but together they form the company.
Similarly, each microservice is independent, but together they form the
application.
CHARACTERISTICS:
- Loose Coupling – Each service is independent.
- Independent Deployment – Services can be deployed
separately.
- Polyglot Persistence – Each service can use its own
database.
- Scalability – Scale only required services.
- Resilience – One service failing doesn’t bring down
the whole system.
 WHY
MICROSERVICES?
(REAL PROBLEM
WITH MONOLITHS)
In the old days, applications were built as a monolith (one big codebase + one big
database).
Example: An e-commerce website (Amazon, Flipkart):
User Management
Product Catalog
Orders
Payments
Notifications
If this was monolithic:
All features are tightly packed into one system.
If you want to change just the payment module, you still need to deploy the entire
application again.
If the order system crashes, the whole site may stop working.
If sales increase and you need to scale only the product service, you must scale the
entire monolith, wasting resources.
COMPONENTS OF
MICROSERVICES
ARCHITECTURE
•Services – Small, independent business modules.
Example: Payment Service, Order Service, User Service.
•API Gateway – A single entry point for all clients (mobile, web).
•Client doesn’t need to know internal services.
•Example: Netflix API Gateway routes user requests to video service,
recommendation service, etc.
•Service Registry – Keeps track of all running services and their addresses.
•Example: If Order Service changes its server, Service Registry updates
the location.
Database per Service – Each service has its own database.
Example: User Service → User DB, Product Service → Product DB.
Prevents tight coupling.
CORE IDEA OF
MICROSERVICES
Break the application into independent modules (services):
User Service – Handles login, signup, profile
Product Service – Handles product catalog
Order Service – Handles customer orders
Payment Service – Handles online payments
Notification Service – Sends emails & SMS
Each service is:
Independent (can be developed, deployed, scaled separately)
Loosely Coupled (connected only through APIs)
Owned by a specific team (e.g., Payments team only
manages Payment Service)
•Inter-service Communication –
• Sync → REST, gRPC
• Async → Message Brokers like Kafka, RabbitMQ

•Configuration Server – Central place to manage

configurations (ports, URLs, secrets).
•Monitoring & Logging – Tools like ELK (Elasticsearch,
Logstash, Kibana), Prometheus, Grafana to check health &
logs.
•Load Balancer – Distributes requests among service
instances.
•Containerization & Orchestration – Docker + Kubernetes
to deploy and manage microservices.
REAL-WORLD EXAMPLE:
AMAZON
Amazon is one of the best real-world examples of
microservices.
User Service → Manages user accounts, profiles
Product Service → Shows product listings
Cart Service → Handles shopping cart
Order Service → Places orders
Payment Service → Processes payments
Recommendation Service → Suggests products (AI-
based)
Notification Service → Sends emails, SMS, push
notifications
BENEFITS IN AMAZON:

During Diwali Sale, Amazon can scale only Product

Service & Order Service instead of the entire
system.
If Recommendation Service fails, users can still
order products.
Each team (Payments, Orders, Products) can work
independently.
 ADVANTAGES OF
MICROSERVICES

•Scalability → Scale only the service that is under heavy load.

•Flexibility → Use different tech stacks for different services
(Java for Payments, [Link] for Notifications).
•Fault Isolation → If one service fails, others keep running.
•Faster Deployment → Deploy services independently.
•Better Team Productivity → Small teams own and
manage specific services.