UNIT -1

System design is a complex and multi-faceted process that involves creating a blueprint for
building a system that meets specific requirements. It encompasses the architectural,
structural, and functional aspects of a system, aiming to ensure that the final product is
effective, efficient, and reliable.

Key Aspects of System Design:

1. Architectural Design:
o Definition: The high-level structure of the system, outlining its components
and their interactions.
o Purpose: To provide an overall view of how the system will be organized and
how different parts will work together.
o Components: Includes modules, services, databases, user interfaces, and
external systems.
2. Functional Design:
o Definition: Specifies what the system will do, focusing on the functionalities
it must provide.
o Purpose: To translate user requirements into specific system capabilities.
o Examples: User authentication, data processing, reporting.
3. Non-Functional Design:
o Definition: Defines how the system performs its functions, addressing aspects
like performance, scalability, and security.
o Purpose: To ensure that the system meets quality standards and can handle
various operational conditions.
o Examples: Response time, system availability, data integrity.
4. Component Design:
o Definition: Details the internal structure and behavior of each system
component.
o Purpose: To ensure that individual components function correctly and
efficiently within the larger system.
o Components: Modules, classes, functions, and data structures.
5. Data Design:
o Definition: Defines how data will be stored, managed, and accessed.
o Purpose: To ensure data integrity, efficient retrieval, and effective storage.
o Examples: Database schema, data models, data access patterns.
6. Interface Design:
o Definition: Specifies how different components of the system will interact
with each other and with external systems.
o Purpose: To ensure seamless integration and communication between
components.
o Examples: APIs, communication protocols, user interfaces.
7. Security Design:
o Definition: Focuses on protecting the system from unauthorized access and
ensuring data privacy and integrity.
o Purpose: To safeguard the system and its data against potential threats.
o Examples: Encryption, authentication mechanisms, access controls.
8. Scalability and Performance:
 o Scalability: The ability of the system to handle increased load by adding
resources (horizontal or vertical scaling).
o Performance: How efficiently the system operates, including factors like
response time and throughput.
9. Reliability and Availability:
o Reliability: The system’s ability to function correctly over time.
o Availability: The proportion of time the system is operational and accessible.

System Design Process:

1. Requirement Analysis:
o Gather and analyze requirements from stakeholders.
o Define both functional and non-functional requirements.
2. High-Level Design:
o Develop the system architecture and identify key components.
o Create diagrams like system architecture diagrams and high-level data flow
diagrams.
3. Detailed Design:
o Specify the details of each component and their interactions.
o Develop detailed design documents, including data schemas, class diagrams,
and interface definitions.
4. Prototyping:
o Create prototypes to validate design concepts and gather feedback.
o Iterate on the design based on testing and feedback.
5. Implementation:
o Develop the system based on the design documents.
o Code, test, and integrate individual components.
6. Testing and Validation:
o Verify that the system meets the requirements and functions as expected.
o Perform various tests, including unit, integration, and system testing.
7. Deployment:
o Release the system into the production environment.
o Ensure that it is properly installed and configured.
8. Maintenance:
o Provide ongoing support and updates to address issues and improve the
system.
o Monitor performance and make necessary adjustments.

System design is essential for creating systems that are robust, scalable, and maintainable. It
requires a thorough understanding of both technical and business requirements and involves
collaboration among various stakeholders, including engineers, designers, and project
managers.

1. Functional vs Non-Functional Requirements

Functional Requirements
  Definition: Describe specific behaviors or functions of the system.
 Purpose: What the system should do.
 Examples:
o User authentication (login/logout).
o Data entry and validation.
o Transaction processing.
 Focus: Specific actions and interactions.

Non-Functional Requirements

 Definition: Describe the quality attributes, constraints, and performance criteria of the
system.
 Purpose: How the system performs its functions.
 Examples:
o Performance (response time, throughput).
o Scalability (ability to handle growing amounts of work).
o Security (encryption, access control).
o Usability (user interface design, accessibility).
 Focus: System quality and performance.

2. Components of System Design

Architecture

 Definition: High-level structure of the system.

 Includes: Components, their interactions, and patterns.

Modules

 Definition: Independent units of functionality.

 Characteristics: Encapsulation, reusability.

Interfaces

 Definition: Points of interaction between different modules or systems.

 Types: API endpoints, message queues.

Data Flow

 Definition: Movement of data through the system.

 Includes: Input sources, processing stages, output destinations.

Storage

 Definition: Mechanisms for data persistence.

 Types: Databases, file systems.

Communication
  Definition: Methods and protocols for component interaction.
 Types: HTTP/HTTPS, messaging protocols, RPC.

3. System Design Life Cycle (SDLC)

Stages

1. Requirement Gathering:
o Collect and document requirements.
o Stakeholder interviews, surveys.
2. System Design:
o High-level architecture and detailed design.
o Data models, system interfaces.
3. Implementation:
o Coding and development of system components.
o Unit testing and code reviews.
4. Testing:
o System testing against requirements.
o Includes functional, integration, and acceptance testing.
5. Deployment:
o Release the system to production.
o Includes deployment strategies, roll-out plans.
6. Maintenance:
o Ongoing support and updates.
o Bug fixes, performance tuning.

4. Structured Analysis and Structured Design (SA/SD)

Structured Analysis

 Focus: Understanding and modeling requirements.

 Techniques:
o Data Flow Diagrams (DFDs): Visualize data movement.
o Entity-Relationship Diagrams (ERDs): Model data relationships.
 Goal: Detailed understanding of system requirements and data.

Structured Design

 Focus: Detailed design of the system architecture.

 Techniques:
o Modular design: Breaking the system into smaller modules.
o Pseudo-code and flowcharts: Detailing the logic and data flow.
 Goal: Blueprint for implementation.

5. System Design Strategy

Top-Down Approach
  Definition: Start with a broad view and break it down into smaller components.
 Advantages: Clear overall vision, easier integration.

Bottom-Up Approach

 Definition: Start with detailed design of individual components and integrate them.
 Advantages: Focus on details first, can be effective for complex systems.

Iterative Design

 Definition: Develop the system in repeated cycles.

 Advantages: Flexibility, continuous improvement based on feedback.

6. Database Sharding –
Sharding

 Definition: Splitting a large database into smaller, more manageable pieces (shards).
 Purpose: Improve performance, scalability, and availability.
 Types:
o Horizontal Sharding: Distribute rows across shards.
o Vertical Sharding: Distribute columns across shards.

Benefits

 Performance: Reduced load on individual shards.

 Scalability: Ability to add more shards to handle increased load.
 Availability: Fault tolerance and redundancy.

7. System Design – Horizontal and Vertical Scaling

Horizontal Scaling

 Definition: Adding more instances of a resource (e.g., more servers).

 Benefits: Better load distribution, high availability.
 Use Cases: Web servers, distributed databases.

Vertical Scaling

 Definition: Increasing resources of a single instance (e.g., more CPU, memory).

 Benefits: Simpler management, fewer changes to the application.
 Limitations: Hardware limits, potential single point of failure

.
1. Overview of Load Balancers
1.1 Definition

A load balancer is a device or software that distributes incoming network or application

traffic across multiple servers. This helps ensure that no single server becomes overwhelmed,
enhancing performance, reliability, and scalability.

1.2 Role in System Design

 Traffic Distribution: Balances traffic across servers to prevent any single server
from becoming a bottleneck.
 Fault Tolerance: Provides redundancy by rerouting traffic from failed servers to
healthy ones.
 Scalability: Facilitates the addition or removal of servers to handle varying loads.

2. Types of Load Balancers

2.1 Hardware Load Balancers

 Description: Physical devices designed to handle high-performance traffic

management.
 Pros: High performance and reliability, often used in large-scale data centers.
 Cons: Expensive, less flexible, hardware-dependent.

2.2 Software Load Balancers

 Description: Software applications running on standard hardware or virtual machines.

 Nginx,HAproxy,apache raffic server
 Pros: Flexible, cost-effective, easier to update and scale.
 Cons: Performance depends on underlying hardware, may require more management.

2.3 Cloud-Based Load Balancers

 Description: Managed services offered by cloud providers like AWS, Azure, and
Google Cloud.
 Pros: Scalable, integrated with cloud services, reduced operational overhead.
 Cons: Costs can add up, less control over underlying infrastructure.

3. Load Balancing Algorithms

3.1 Round Robin

 Description: Distributes requests sequentially across a pool of servers.

  Use Case: Simple and effective for evenly distributing traffic when server capabilities
are similar.

3.2 Least Connections

 Description: Routes traffic to the server with the fewest active connections.
 Use Case: Ideal for varying server loads, helps balance the load dynamically based on
server utilization.

3.3 Least Response Time

 Description: Sends requests to the server with the lowest response time.
 Use Case: Useful when response time varies significantly between servers.

3.4 IP Hashing

 Description: Routes requests based on a hash of the client’s IP address.

 Use Case: Maintains session consistency by directing requests from the same client IP
to the same server.

3.5 Weighted Algorithms

 Description: Assigns weights to servers based on their capacity and routes traffic
accordingly.
 Use Case: Suitable for heterogeneous environments where servers have different
capacities.

4. Session Persistence (Sticky Sessions)

4.1 Cookie-Based Persistence

 Description: Uses cookies to track and route requests from the same client to the
same server.
 Pros: Simple to implement.
 Cons: Depends on client-side storage, may not be suitable for all scenarios.

4.2 Session Affinity

 Description: Ensures requests from a particular session are consistently directed to

the same server.
 Pros: Maintains session state.
 Cons: Can lead to uneven load distribution if not managed properly.

5. Health Checks
5.1 Types of Health Checks

 HTTP/HTTPS Checks: Verify the server responds correctly to HTTP/HTTPS

requests.
 TCP Checks: Ensure the server’s TCP port is open and accepting connections.
 Custom Checks: Application-specific checks to validate server health.

5.2 Configuration

 Interval: Frequency of health checks.

 Timeout: Time to wait for a response before considering the server unhealthy.
 Thresholds: Number of successful or failed checks required to mark a server as
healthy or unhealthy.

6. SSL Termination
6.1 Description

 SSL Offloading: The load balancer handles SSL/TLS encryption and decryption,
reducing the computational load on backend servers.

6.2 Benefits

 Simplifies Certificate Management: Centralizes SSL certificate handling.

 Improves Backend Performance: Offloads CPU-intensive encryption tasks from
application servers.

6.3 Considerations

 Traffic Between Load Balancer and Servers: Ensure that traffic between the load
balancer and backend servers is secured if SSL is terminated at the load balancer.

7. Load Balancer Placement

7.1 Front-End Placement

 Description: Positioned in front of application servers to manage incoming traffic

from clients.
 Benefits: Provides a single point of access, simplifies client connections.

7.2 Internal Placement

 Description: Used within the data center or cloud environment to balance traffic
among internal services or microservices.
  Benefits: Enhances internal service communication and scalability.

8. Advantages of Load Balancers

8.1 Performance Enhancement

 Description: Distributes load to prevent server bottlenecks, improving overall system

performance.

8.2 Reliability and Redundancy

 Description: Provides failover and redundancy, ensuring higher availability and

reliability.

8.3 Maintenance Flexibility

 Description: Allows for rolling updates and maintenance without impacting service
availability.

9. Challenges and Considerations

9.1 Single Point of Failure

 Description: A single load balancer can become a point of failure if not properly
managed.
 Mitigation: Use redundant load balancers and ensure high availability configurations.

9.2 Complexity

 Description: Configuring and managing load balancers can introduce complexity.

 Mitigation: Implement automation and monitoring tools to manage complexity.

9.3 Cost

 Description: Cloud-based load balancers can incur significant costs, especially at

high traffic levels.
 Mitigation: Evaluate cost-benefit trade-offs and optimize usage.

10. Security Considerations

10.1 DDoS Mitigation
  Description: Load balancers can absorb and mitigate Distributed Denial of Service
(DDoS) attacks.
 Benefit: Protects backend servers and ensures availability during attacks.

10.2 Access Control

 Description: Enforce access control policies and rate limiting to enhance security.
 Benefit: Controls and monitors access to backend services.

11. Monitoring and Logging

11.1 Metrics

 Description: Track key metrics such as request rates, response times, and server
health.
 Benefit: Provides insights into performance and helps identify potential issues.

11.2 Logging

 Description: Maintain logs for debugging, performance analysis, and auditing.

 Benefit: Facilitates troubleshooting and performance monitoring.

12. Integration with Other Components

12.1 Content Delivery Networks (CDNs)

 Description: Work with CDNs to cache and deliver content efficiently.

 Benefit: Reduces server load and improves content delivery speed.

12.2 Service Discovery

 Description: Integrate with service discovery mechanisms to dynamically update

server pools.
 Benefit: Ensures load balancers route traffic to available and correct services.

13. Considerations for Choosing a Load Balancer

13.1 Traffic Volume and Performance

 Description: Assess the expected traffic volume and performance requirements.

 Consideration: Choose a load balancer that can handle the load and provide required
performance.
13.2 Application Architecture

 Description: Consider how the load balancer fits into the application’s architecture
(monolithic, microservices, etc.).
 Consideration: Ensure compatibility and support for your architectural needs.

13.3 Cost and Budget

 Description: Evaluate costs, especially for cloud-based solutions.

 Consideration: Balance cost with required features and performance.

9. Routing Requests through Load Balancer

Request Routing

 Definition: Directing incoming requests to different servers.

 Methods:
o Round-Robin: Distribute requests evenly.
o Least Connections: Direct to the server with the fewest active connections.
o IP Hashing: Route based on the client’s IP address.

Benefits

 Improved Performance: Better load distribution.

 Increased Reliability: Failover support if a server goes down.

10. Latency and Throughput in System Design

Latency

 Definition: The time taken for a request to travel from the source to the destination
and back.
 Factors Affecting Latency: Network speed, server processing time, database queries.

Throughput

 Definition: The amount of data processed by the system in a given time period.
 Factors Affecting Throughput: System architecture, resource allocation, network
capacity.

11. Object-Oriented Analysis and Design (OOAD)

Object-Oriented Analysis

 Definition: Analyzing requirements using object-oriented concepts.

  Focus: Identifying objects, their attributes, and relationships.

Object-Oriented Design

 Definition: Designing the system using object-oriented principles.

 Principles:
o Encapsulation: Bundling data and methods.
o Inheritance: Reusing common behavior.
o Polymorphism: Different implementations for the same interface.

12. Difference between Structured and Object-Oriented

Analysis
Structured Analysis

 Focus: Processes and data flows.

 Techniques: Data Flow Diagrams, Entity-Relationship Diagrams.
 Approach: Top-down, process-oriented.

Object-Oriented Analysis

 Focus: Objects, their attributes, and interactions.

 Techniques: UML (Unified Modeling Language), class diagrams.
 Approach: Bottom-up, object-oriented.