https://www.geeksforgeeks.

org/system-design-tutorial/

--------------------- ------------------------------------------------------------- --------------------------------------

1|Page
MID Syllabus

 Basics of System Design: Functional vs Non Functional Requirements,

Components of System Design, System Design Life Cycle (SDLC),
Structured Analysis and Structured Design (SA/SD), System Design
Strategy, Database Sharding – System Design Interview Concept,
System Design – Horizontal and Vertical Scaling, Load Balancer in
System Design, Routing requests through Load Balancer, Latency and
Throughput in System Design, Object-Oriented Analysis and Design,
Difference between Structured and Object-Oriented Analysis.

 Scalability in System Design: Achieving scalability, Scalability

approaches for an Application, Primary Bottlenecks that Hurt the
Scalability of an Application.

 Databases in Designing Systems: Choosing Database while designing

a system – SQL or NoSQL, File and Database Storage Systems in
System Design, Database Replication in System Design, Block, Object,
and File Storage, Normalization Process in DBMS, Denormalization in
Databases.

System Design

System Design is the process of designing the architecture, components, and interfaces
for a system so that it meets the end-user requirements.

System design is the process of designing the architecture and components of a software
system to meet specific business requirements. The process involves defining the
system’s architecture, components, modules, and interfaces, and identifying the
technologies and tools that will be used to implement the system.

Basics of System Design

Steps for getting started with System Design

Here are some steps to get started with system design:

1. Understand the requirements:

 Before you begin designing the system, you need to understand the requirements. This involves
talking to stakeholders and users, reviewing existing documentation, and analyzing the business
processes that the system will support.

2. Define the system architecture:

 Once you have a clear understanding of the requirements, you can begin defining the system
architecture. This involves identifying the major components of the system and the interfaces
between them.

3. Choose the technology stack:

2|Page
  Based on the requirements and the system architecture, you can select the technology stack. This
includes choosing the programming language, database, frameworks, and libraries that will be
used to implement the system.

4. Design the modules:

 Next, you need to design the modules that will make up the system. This involves defining the
functions that each module will perform and the data that it will manipulate.

5. Plan for scalability:

 As you design the system, you need to consider how it will scale. This involves identifying
potential bottlenecks and designing the system to handle increased loads.

6. Consider security and privacy:

 Security and privacy should be a key consideration in system design. This involves identifying
potential security threats and designing the system to mitigate them.

7. Test and validate:

 Once the system design is complete, you need to test and validate it. This involves creating test
cases and scenarios that simulate real-world usage and verifying that the system meets the
requirements.

Overall, system design is a complex process that requires careful planning and attention to detail. By following
these steps, you can create a system design that meets the needs of your users and your business.

Tips and Tricks to solve System Design Problem

 When you are given a System Design Problem, you should approach it in a planned manner.

 Initially, the Problem may look huge, and one can easily get confused about how to start solving it.

 And moreover, there is no fixed solution while you are designing a system.

 There is more than one way to reach the Solution.

So let’s discuss how one should start with solving a Design Problem given in an Interview.

Approaching a Design Problem

1. Breaking Down the Problem

When you are given a Design Problem start breaking it down into small components. These components can be
Services or Features which you need to implement in the System.

 Initially, a System given to be designed can have a large number of features and you are not expected to
design everything if it’s an Interview.

2. Communicating your Ideas

Communicate well with the Interviewer:

 While designing the system keep him in the loop.

 Discuss your process out loud.

 Try to demonstrate your design clearly on the whiteboard with flowcharts and diagrams.
3|Page
  Describe your ideas to your interviewer, how you have planned to tackle the problem of scalability, how
you will be designing your database, and many others.

3. Assumptions that make sense

Make some reasonable assumptions while you are designing the System.

Suppose you have to assume the number of requests the system will be processed per day, the number of
database calls made in a month, or the efficiency rate of your Caching System. These are some of the numbers you
need to assume while designing. Try to keep these numbers as reasonable as possible. Back up your assumption
with some solid facts and figures.

Now we know how to approach a design problem. But in order to succeed in the Interview or to successfully build
a scalable system, we need to ensure that our system is reliable, available, scalable, and maintainable. So we
should have knowledge of what these terms are and how they impact our system in the long run.

Reliability in System Design

A system is Reliable when it can meet the end-user requirement. When you are designing a system you should
have planned to implement a set of features and services in your system. If your system can serve all those
features without wearing out then your System can be considered to be Reliable.

A Fault Tolerant system can be one that can continue to be functioning reliably even in the presence of faults.

 Faults are the errors that arise in a particular component of the system. An occurrence of fault doesn’t
guarantee Failure of the System.

 Failure is the state when the system is not able to perform as expected. It is no longer able to provide
certain services to the end-users.

Availability in System Design

Availability is a characteristic of a System that aims to ensure an agreed level of Operational Performance, also
known as uptime. It is essential for a system to ensure high availability in order to serve the user’s requests. The
extent of Availability varies from system to system.

 Suppose you are designing a Social Media Application then high availability is not much of a need. A delay
of a few seconds can be tolerated. Getting to view the post of your favorite celebrity on Instagram with a
delay of 5 to 10 seconds will not be much of an issue.

 But if you are designing a system for hospitals, Data Centers, or Banking, then you should ensure that
your system is highly available, Because a delay in the service can lead to a huge loss.

 There are various principles you should follow in order to ensure the availability of your system .

4|Page
 o Your System should not have a Single Point of Failure.
o Basically, your system should not be dependent on a single service in order to process all of its
requests. Because when that service fails then your entire system will end up becoming
unavailable.
o Detecting the Failure and resolving it at that point.

Scalability in System Design

Scalability refers to the ability of the System to cope with the increasing load. While designing the system you
should keep in mind the load experienced by it. It’s said that if you have to design a system for load X then
you should plan to design it for 10X and Test it for 100X. There can be a situation where your system can
experience an increasing load.

 Suppose you are designing an E-commerce application then you can expect a spike in the load during a
Flash Sale or when a new Product is Launched for sale.

 In that case, your system should be smart enough to handle the increasing load efficiently and that makes
it Scalable.

 In order to ensure scalability you should be able to compute the load that your system will experience.

There are various factors that describe the Load on the System:

 Number of requests coming to your system for getting processed per day

 Number of Database calls made from your system

 Amount of Cache Hit or Miss requests to your system

 Users currently active on your system

Important points to consider when designing a software system:

1. Scalability: The system should be designed to handle increased loads and be able to scale horizontally or
vertically as needed.

2. Performance: The system should be designed to perform efficiently and effectively, with minimal latency
and response time.

3. Reliability: The system should be reliable and available, with minimal downtime or system failures.

4. Security: The system should be designed with security in mind, including measures to prevent
unauthorized access and protect sensitive data.

5. Maintainability: The system should be designed to be easy to maintain and update, with clear
documentation and well-organized code.

6. Interoperability: The system should be designed to work seamlessly with other systems and components,
with clear and well-defined interfaces.

7. Usability: The system should be designed to be user-friendly and intuitive, with a clear and consistent
user interface.

8. Cost-effectiveness: The system should be designed to be cost-effective, with a focus on minimizing

development and operational costs while still meeting the requirements.

Advantages of designing a software system

5|Page
  Improved Efficiency: A well-designed system can help improve efficiency by automating repetitive tasks,
reducing errors, and increasing productivity.

 Scalability: A well-designed system can easily scale up or down as needed to accommodate changes in
business requirements or user demand.

 Improved User Experience: A well-designed system can provide a better user experience, making it easier
for users to accomplish their goals and increasing user satisfaction.

 Better Security: A well-designed system can help improve security by implementing best practices for
security and data protection.

 Better Integration: A well-designed system can easily integrate with other systems or applications,
improving interoperability and reducing complexity.

Disadvantages of designing a software system

 Increased Complexity: As systems become more complex, they can become more difficult to design,
develop, and maintain.

 Increased Cost: Designing a complex system can be expensive, requiring significant resources and
expertise.

 Longer Development Time: Designing a complex system can take longer to develop than a simpler
system, potentially delaying the delivery of the system.

 Higher Risk of Failure: As systems become more complex, they may be more prone to failure, requiring
additional resources to diagnose and fix issues.

 Difficulty in Adapting to Change: A complex system may be more difficult to modify or adapt to changing
business requirements or technology trends.

By keeping these points in mind, you can design a software system that is effective, efficient, and meets the
needs of your users and business.

Functional vs. Non Functional Requirements

Requirements analysis is an essential process that enables the success of a system or software project to be
assessed. Requirements are generally split into two types: Functional and Non-functional requirements.
functional requirements define the specific behavior or functions of a system—what the system should do to
meet user needs. These include features like data processing, authentication, and user interactions. In contrast,
non-functional requirements specify how the system performs its tasks, focusing on attributes like performance,
security, scalability, and usability.

6|Page
What are Functional Requirements?

These are the requirements that the end user specifically demands as basic facilities that the system should offer.
All these functionalities need to be necessarily incorporated into the system as a part of the contract.

These are represented or stated in the form of input to be given to the system, the operation performed and the
output expected. They are the requirements stated by the user which one can see directly in the final product,
unlike the non-functional requirements.

Examples:
 What are the features that we need to design for this system?
 What are the edge cases we need to consider, if any, in our design?

What are Non-Functional Requirements?

These are the quality constraints that the system must satisfy according to the project contract. The priority or
extent to which these factors are implemented varies from one project to another. They are also called non-
behavioral requirements. They deal with issues like:

 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
Examples:

 Each request should be processed with the minimum latency?

 System should be highly valuable.

What are Extended Requirements?

These are basically “nice to have” requirements that might be out of the scope of the System.

Example:

7|Page
  Our system should record metrices and analytics.

 Service heath and performance monitoring.

Differences between Functional Requirements and Non-Functional Requirements:

Below are the differences between Functional Requirements and Non-Functional Requirements:

Aspect Functional Requirements Non-Functional Requirements

Describes what the system should do, i.e., Describes how the system should perform,
Definition specific functionality or tasks. i.e., system attributes or quality.

Focuses on the behavior and features of Focuses on the performance, usability, and
Purpose the system. other quality attributes.

Defines the actions and operations of the Defines constraints or conditions under
Scope system. which the system must operate.

User authentication, data input/output, Scalability, security, response time,

Examples transaction processing. reliability, maintainability.

Easy to measure in terms of outputs or More difficult to measure, often assessed

Measurement results. using benchmarks or SLAs.

Impact on Drives the core design and functionality of Affects the architecture and overall
Development the system. performance of the system.

Focus on User Directly related to user and business Focuses on user experience and system
Needs requirements. performance.

Typically documented in use cases, functional Documented through performance criteria,

Documentation specifications, etc. technical specifications, etc.

Can be tested through functional testing (e.g., Evaluated through performance testing, security
Evaluation unit or integration tests). testing, and usability testing.

Determines what the system must do to meet Depends on how well the system performs the
Dependency user needs. required tasks.

Importance of Balancing Both Functional and Non-Functional Requirements

Balancing both functional and non-functional requirements is crucial in system design because they address
different yet equally important aspects of the system. Here’s why balancing them is essential:

 Improves User Experience: Focusing only on functional requirements may result in a system that works
but is slow, unresponsive, or difficult to use. Non-functional requirements like usability, performance, and
availability significantly impact how users interact with the system and their satisfaction.

 Enhances System Performance: Non-functional aspects like scalability, reliability, and security ensure the
system performs well under real-world conditions. A system that meets functional needs but fails to scale
8|Page
 or handle a large number of users can result in failure. Balancing these ensures that the system not only
works but works efficiently.

 Prevents Bottlenecks and Failures: Systems with strong functional performance but poor security or
reliability are prone to outages, breaches, or failures. By considering non-functional requirements, the
system becomes more resilient and less prone to bottlenecks.

 Reduces Long-Term Costs: Systems designed with only functional requirements in mind often encounter
scalability and maintainability issues as they grow. Addressing non-functional requirements early on
prevents costly changes, re-architecting, or performance enhancements later.

 Supports System Evolution: Non-functional requirements such as maintainability and extensibility make
future updates, feature additions, and system scaling easier and less disruptive. This balance ensures that
the system can evolve and adapt over time without significant hurdles.

Common Challenges in Defining these Requirements

Defining both functional and non-functional requirements in system design can be challenging due to several
factors. Here are some common challenges:

 Ambiguity in Requirements:

o Challenge: Requirements are often unclear, making it difficult to interpret what the system
should do (functional) and how it should perform (non-functional).

o Impact: This can lead to misunderstandings between stakeholders and developers, resulting in
incomplete or incorrect system implementation.

 Changing Requirements:

o Challenge: As projects evolve, functional and non-functional requirements often change due to
shifting business goals, market trends, or user needs.

o Impact: Frequent changes disrupt the development process, increase costs, and lead to scope
creep.

 Difficulty in Prioritization:

o Challenge: Deciding which functional and non-functional requirements are most important is
often difficult. Functional needs can overshadow non-functional ones, such as security or
scalability.

o Impact: Without proper prioritization, critical non-functional aspects might be overlooked,

leading to system failures or performance bottlenecks later.

 Measuring Non-Functional Requirements:

o Challenge: Functional requirements are often straightforward to test, but non-functional

requirements like usability, scalability, and reliability are harder to measure and validate.

o Impact: Developers may struggle to validate if the system meets expectations for performance,
security, or scalability.

 Overlapping or Conflicting Requirements:

9|Page
 o Challenge: Sometimes, functional and non-functional requirements can overlap or conflict. For
example, adding complex security features (non-functional) might slow down the performance
(another non-functional requirement).

o Impact: This can create trade-offs and force difficult decisions, affecting the overall system design.

What are the components of System Design?

System design is the process of defining the architecture, components, modules, interfaces, and data for a
computer system. It involves analyzing the requirements of the system, identifying the constraints and
assumptions, and defining the high-level structure and components of the system. The goal of system design is to
create a blueprint for the development and implementation of a computer system that meets the needs of the
users and stakeholders.

Components of System Design

 Load Balancer
 Key-value stores
 Blob storage & Databases
 Rate limiters
 Monitoring System
 Distributes system messaging queue
 Distributed unique id generator
 Distributes search
 Distributed logging services
 Distributes task scheduler

1. Load Balancer

A load balancer is a system design component that is used to distribute incoming requests or workloads across a
number of different resources or servers. This can be useful in a number of different scenarios, such as when a
system receives a large number of requests and needs to distribute them among multiple servers to avoid
overloading any one server, or when a system has multiple servers and needs to distribute requests evenly among
them to ensure that all servers are utilized efficiently.

There are many different types of load balancers, and the specific type that is used in a given system will depend
on the specific requirements of the system. Some common types of load balancers include:

 Layer 4 load balancers operate at the network layer of the OSI model and distribute requests based on
the source and destination IP addresses and port numbers of the requests.

 Layer 7 load balancers operate at the application layer of the OSI model and distribute requests based on
the content of the requests, such as the URL or the type of HTTP method used.

10 | P a g e
  Global load balancers are used in distributed systems to distribute requests among multiple servers
located in different geographic regions.

 Application load balancers are specialized load balancers that are designed to work with specific types of
applications or protocols, such as HTTP or HTTPS.

In general, a load balancer is a key component of many system designs and can play a critical role in ensuring that
a system can handle a large number of requests efficiently and without overloading any of its resources.

2. Key-value stores
A key-value store is a type of NoSQL database that is designed to store data as a set of key-value pairs. In a
key-value store, each piece of data is stored under a unique key, and the value is the data itself. Key-value
stores are often used to store data that is accessed frequently, as they can provide fast access to data by key.

 There are several different types of key-value stores, including in-memory key-value stores, which store
data in memory for fast access, and persistent key-value stores, which store data on disk or in a
distributed file system for durability. Key-value stores can be used in a variety of applications, including
caching, session management, and real-time analytics.

 Key-value stores are generally simpler to use and more scalable than other types of databases, such as
relational database management systems (RDBMS). However, they are not as well-suited for storing
complex, structured data that requires advanced querying capabilities.

In a distributed system, key-value stores can be used to store data that needs to be accessed quickly and
consistently across multiple nodes. They can also be used to store metadata and other auxiliary data that is used
by the system. It is important to choose the right type of key-value store for the specific requirements of the
system, taking into account factors such as scalability, performance, and durability.

3. Blob storage & Databases

Blob storage and database systems are two different types of storage systems that can be used to store and
manage data.

Blob storage, also known as object storage, is a type of storage system that is designed to store large amounts of
unstructured data, such as documents, images, videos, and audio files. Blob storage systems are typically highly
scalable and can handle a large number of requests concurrently. They are often used to store data that is
accessed frequently, such as media files or user-generated content.

 Database systems, on the other hand, are designed to store structured data that is organized in a specific
way.

 There are several different types of database systems, including relational database management systems
(RDBMS), NoSQL databases, and in-memory databases.

 Database systems are typically used to store data that needs to be queried and accessed in a structured
way, such as customer records or financial transactions.

Blob storage and database systems can be used together in a distributed system to store and manage different
types of data. For example, a distributed system might use a blob storage system to store unstructured data such
as user-generated content, and a database system to store structured data such as customer records and
transactions. It is important to choose the right type of storage system for each type of data, taking into account
the specific requirements of the system and the needs of the users.

4. Rate limiters

11 | P a g e
Rate limiters are system design components that are used to limit the rate at which a system or application
processes requests or performs certain actions. This can be useful in a number of different scenarios, such as
when a system needs to protect itself from being overloaded by too many requests, or when an organization
wants to prevent a specific user or group of users from making excessive requests that could impact the
performance of a system.

There are many different types of rate limiters, and the specific type that is used in a given system will depend on
the specific requirements of the system. Some common types of rate limiters include:

 Request rate limiters are used to limit the number of requests that a system or application processes
within a given time period.

 Action rate limiters are used to limit the number of times that a specific action or operation can be
performed within a given time period.

 User rate limiters are used to limit the rate at which a specific user or group of users can make requests
to a system or application.

 Token bucket rate limiters are used to limit the rate at which requests are processed by a system by
allowing a certain number of requests to be processed in each time period, with any excess requests
being held in a “bucket” until the next time period.

In general, rate limiters are a useful component of many system designs, and can play a key role in ensuring that a
system is able to handle a high volume of requests without being overwhelmed. By limiting the rate at which
requests are processed, rate limiters can help prevent a system from being overloaded or degraded, and can help
ensure that it is able to provide consistent and reliable performance.

5. Monitoring System

A monitoring system is a system design component that is used to collect, analyze, and report on various metrics
and performance data related to a system or application. This can be useful in a number of different scenarios,
such as when a system needs to track its own performance and availability, or when an organization needs to
monitor the performance of its systems and applications to ensure that they are meeting their desired service
levels.

There are many different types of monitoring systems, and the specific type that is used in a given system will
depend on the specific requirements of the system. Some common types of monitoring systems include:

 Network monitoring systems, are used to monitor the performance of a network and its various
components, such as routers, switches, and servers.

 System monitoring systems, are used to monitor the performance of a computer system and its various
components, such as the CPU, memory, and disk usage.

 Application monitoring systems, are used to monitor the performance of specific applications or services,
such as web servers or databases.

 Infrastructure monitoring systems, are used to monitor the performance of the underlying infrastructure
on which a system or application is running, such as virtual machines or containers.

In general, a monitoring system is a critical component of many system designs and can play a key role in ensuring
that a system is performing well and meeting its desired service levels. By providing real-time visibility into the
performance of a system, a monitoring system can help identify and troubleshoot issues as they arise, and can
provide valuable insights into the overall health and availability of a system.

12 | P a g e
6. Distributes system messaging queue

A distributed system messaging queue is a system that enables the exchange of messages between different
nodes in a distributed system. Messaging queues allow nodes to communicate asynchronously, decoupling the
sender and receiver of a message and enabling each node to operate independently.

There are several different types of messaging queues, including:

 Point-to-point queues: In this type of queue, messages are delivered to a specific recipient.

 Publish-subscribe queues: In this type of queue, messages are published to a topic and are delivered to
all subscribers to that topic.

 Hybrid queues: Hybrid queues combine elements of both point-to-point and publish-subscribe queues,
allowing messages to be delivered to specific recipients or to all subscribers to a topic.

Distributed system messaging queues can be used to enable communication between different components of a
distributed system, such as microservices or distributed applications. They can also be used to decouple different
parts of the system, allowing each component to operate independently and improving the system’s resilience
and scalability.

There are several tools and frameworks available for implementing distributed system messaging queues,
including Apache Kafka, RabbitMQ, and Amazon Simple Queue Service (SQS). It is important to choose a
messaging queue that meets the specific requirements of your system, taking into account factors such as
scalability, performance, and fault tolerance.

7. Distributed unique id generator

A distributed unique ID generator is a system that generates unique identifiers (IDs) that can be used to identify
objects or entities in a distributed system. These IDs are typically used to uniquely identify items in a database or
to provide a stable identifier for a resource that is accessed over the network.

There are several approaches to generating distributed unique IDs :

 Using a centralized service

 Using a distributed consensus algorithm

 Using timestamps

8. Distributes search

Distributed search refers to the practice of using multiple nodes or servers to index and search large datasets in a
distributed system. Distributed search can be used to improve the performance and scalability of search
operations, as it allows for parallel processing of search queries and the distribution of data across multiple
nodes.

There are several approaches to implementing distributed search, including:

 Using a distributed search engine: A distributed search engine is a search platform that is designed to
scale horizontally across multiple nodes. These systems typically use a distributed index to store the data
being searched, allowing for parallel processing of search queries. Examples of distributed search engines
include Elasticsearch and Apache Solr.

13 | P a g e
  Using a database with search capabilities: Some databases, such as MongoDB and Cassandra, have built-
in search capabilities that allow for the indexing and searching of data stored in the database. These
systems can be used to implement distributed search in a distributed system.

 Using a cloud-based search service: Cloud-based search services, such as Amazon Elasticsearch Service
and Google Cloud Search, can be used to implement distributed search in a distributed system. These
services are typically highly scalable and fault-tolerant, and they can be a good choice for organizations
that do not want to manage their own search infrastructure.

In a distributed system, it is important to choose a distributed search solution that meets the specific
requirements of the system, taking into account factors such as scalability, performance, and cost.

9. Distributed logging services

Distributed logging refers to the practice of collecting, storing, and analyzing log data from multiple sources in a
distributed system. This can be useful for tracking the health and performance of a distributed system, as well as
for debugging issues that may arise.

There are several approaches to implementing distributed logging, including:

 Using a centralized logging service

 Using a distributed logging system

 Using a cloud-based logging service

10. Distributes task scheduler

A distributed task scheduler is a system that is responsible for scheduling and executing tasks in a distributed
system. A task scheduler can be used to automate the execution of tasks at regular intervals, on a specific
schedule, or in response to certain events.

There are several approaches to implementing a distributed task scheduler, including:

 Using a standalone task scheduler: A standalone task scheduler is a separate system that is responsible
for scheduling and executing tasks in a distributed system. This approach can be simple to implement and
allows for flexibility in terms of the types of tasks that can be scheduled. However, it can be more
complex to manage and may require additional infrastructure.

 Using a built-in task scheduler: Some distributed systems, such as container orchestration platforms or
cloud-based serverless platforms, have built-in task schedulers that can be used to schedule tasks within
the system. This approach can be simpler to implement and manage but may be less flexible in terms of
the types of tasks that can be scheduled.

 Using a cloud-based task scheduler: Cloud-based task schedulers, such as Amazon Simple Notification
Service (SNS) or Google Cloud Scheduler, can be used to schedule tasks in a distributed system. These
services are typically highly scalable and fault-tolerant, and they can be a good choice for organizations
that do not want to manage their own task-scheduling infrastructure.

It is important to choose a distributed task scheduler that meets the specific requirements of the system, taking
into account factors such as scalability, performance, and cost.

System Design Life Cycle | SDLC (Design)

System Design is the process of designing the architecture, components, and interfaces for a system so that it
meets the end-user requirements.

14 | P a g e
System design is the process of designing the architecture and components of a software system to meet specific
business requirements. The process involves defining the system’s architecture, components, modules, and
interfaces, and identifying the technologies and tools that will be used to implement the system.

System Design Life Cycle is defined as the complete journey of a System from planning to deployment. The
System Design Life Cycle is divided into 7 Phases or Stages, which are:
1. Planning Stage
2. Feasibility Study Stage
3. System Design Stage
4. Implementation Stage
5. Testing Stage
6. Deployment Stage
7. Maintenance and Support

15 | P a g e
Stage 1. Planning

 Objective: Define the project scope, goals, and resources.

 Example: Imagine a company initiating a project to develop a new customer relationship management
(CRM) system. The planning phase would involve outlining the functionalities, budge constraints, and
identifying the team responsible.

Stage 2. Feasibility Study

 Objective: Asses the practicality of the proposed system.

 Example: Before committing to the CRM project, a feasibility study would analyze factors like technical,
operational, and economic viability. This involves evaluating whether the benefits outweigh the costs.

Stage 3. System Design

 Objective: Develop a blueprint of the system architecture and components.

 Example: For the CRM system, this involves creating a detailed design that outlines the database
structure, user interfaces, and system functionalities. It serves as a guide for the developers during the
coding phase.

Stage 4. Implementation

 Objective: Transform the design into an operational system.

 Example: Developers write the code for the CRM system based on the design specifications. This phase
involves rigorous testing to identify and rectify any bugs or errors.

Stage 5. Testing

 Objective: Verify that the system meets the specified requirements.

 Example: The CRM system undergoes various testing procedures, such as unit testing, integration testing,
and user acceptance testing, to ensure its functionality, performance, and security.

Stage 6. Deployment

 Objective: Introduce the system to its intended environment.

 Example: The CRM system is deployed for use by the organization’s employees. This may involves training
sessions to familiarize users with the new system.

Stage 7. Maintenance and Support

 Objective: Ensure the ongoing functionality and address any issues that arise.

 Example: Regular updates, bug fixes, and user support for the CRM system to adapt to changing business
requirements and address any emerging issues.

Challenges in System Design Life Cycle

 Unclear Requirements: Sometime, the initial requirements for a system might be unclear or ambiguous,
leading to difficulties in designing the system accurately.
16 | P a g e
  Changing Requirements: Requirements may change during the design process, posing a challenge to
maintain consistency and ensuring that the system still meets the user’s needs.

 Technological Changes: Rapid advancements in technology can make it challenging to choose the most
suitable and up-to-date technologies for system design.

 Integration Issues: Ensuring seamless integration of various system components can be complex,
especially when dealing with different technologies and platforms.

 Budget Constraints: Designing a system within budgetary constraints can be challenging, as incorporating
certain features or technologies might be cost-productive.

 Security Concerns: Designing a system that is secure from potential threats and vulnerabilities is an
ongoing challenge, as new security risk continually emerge.

 Scalability and Performance: Designing a system to handle scalability and ensuring optimal performance,
especially under heavy loads, can be challenging.

Models Used for System Design Life Cycle

 Waterfall Model: A linear and sequential model where each phase must be completed before moving on
to the next. It’s a straightforward approach but can be inflexible in the face of changing requirements.

 Iterative Model: Involves repeating cycles, with each iteration refining and improving the system based
on feedback. It’s adaptable to changing requirements.

 Prototyping Model: Involves building a prototype (a preliminary version) of the system to gather
feedback refine the design before building the final product.

 Spiral Model: Incorporates elements of both iterative and prototyping models. It involves cycles of
planning, designing, constructing, and evaluating.

 Agile Model: Emphasizes flexibility and collaboration, with frequent iterations and continuous feedback.
It’s well suited for projects where requirements may evolve.

Best Practices in System Design Life Cycle

 Clear Requirement Elicitation: Invest time in thoroughly understanding and documenting requirements
to provide a solid foundation for the design process.

 Regular Stakeholder Communication: Maintain open communication with stakeholders to ensure their
needs are understood and to address any changes promptly.

 Modular Design: Design systems in a modular fashion, allowing for easier maintenance, updates, and
scalability.

 Risk Assessment and Management: Identify potential risks early in the design process and develop
strategies to mitigate or manage them effectively.

 User-Centric Design: Prioritize user experience by incorporating feedback, usability testing, and a focus
on intuitive interfaces.

17 | P a g e
  Documentation: Keep comprehensive documentation through the design process to facilitate
communication, knowledge transfer, and future maintenance.

Use Cases of System Design Life Cycle

The SDLC is used in a wide variety of projects, from developing small applications to building large enterprise
systems. Some common use cases for the SDLC includes:

 Developing new software applications.

 Enhancing existing software applications.

 Integrating different systems together.

 Replacing legacy systems.

 Developing custom solutions for specific business needs.

By following the best practices and using the appropriate SDLC model, organizations can increase their chances of
successfully completing their system development projects.

Conclusion
In conclusion, the System Design Life Cycle (SDLC) plays a pivotal role in shaping the development of robust
and efficient systems. By focusing on the design aspects, it provides a blueprint for constructing systems that
meet user requirements and adhere to industry standards.

Structured Analysis and Structured Design (SA/SD)

Structured Analysis and Structured Design (SA/SD) is a diagrammatic notation that is designed to help people
understand the system. The basic goal of SA/SD is to improve quality and reduce the risk of system failure. It
establishes concrete management specifications and documentation. It focuses on the solidity, pliability, and
maintainability of the system.

Structured Analysis and Structured Design (SA/SD) is a software development method that was popular in the
1970s and 1980s. The method is based on the principle of structured programming, which emphasizes the
importance of breaking down a software system into smaller, more manageable components.

In SA/SD, the software development process is divided into two phases: Structured Analysis and Structured
Design. During the Structured Analysis phase, the problem to be solved is analyzed and the requirements are
gathered. The Structured Design phase involves designing the system to meet the requirements that were
gathered in the Structured Analysis phase.

Structured Analysis and Structured Design (SA/SD) is a traditional software development methodology that was
popular in the 1980s and 1990s. It involves a series of techniques for designing and developing software systems
in a structured and systematic way. Here are some key concepts of SA/SD:

1. Functional Decomposition: SA/SD uses functional decomposition to break down a complex system into
smaller, more manageable subsystems. This technique involves identifying the main functions of the
system and breaking them down into smaller functions that can be implemented independently.

2. Data Flow Diagrams (DFDs): SA/SD uses DFDs to model the flow of data through the system. DFDs are
graphical representations of the system that show how data moves between the system’s various
components.

3. Data Dictionary: A data dictionary is a central repository that contains descriptions of all the data
elements used in the system. It provides a clear and consistent definition of data elements, making it
easier to understand how the system works.
18 | P a g e
 4. Structured Design: SA/SD uses structured design techniques to develop the system’s architecture and
components. It involves identifying the major components of the system, designing the interfaces
between them, and specifying the data structures and algorithms that will be used to implement the
system.

5. Modular Programming: SA/SD uses modular programming techniques to break down the system’s code
into smaller, more manageable modules. This makes it easier to develop, test, and maintain the system.

Some advantages of SA/SD include its emphasis on structured design and documentation, which can help improve
the clarity and maintainability of the system. However, SA/SD has some disadvantages, including its rigidity and
inflexibility, which can make it difficult to adapt to changing business requirements or technological trends.
Additionally, SA/SD may not be well-suited for complex, dynamic systems, which may require more agile
development methodologies.

Structured analysis and design techniques are essential for developing software that meets user requirements.
Understanding these methodologies can greatly enhance your system design capabilities. Explore this System
design course for comprehensive insights into structured analysis and design.

The following are the steps involved in the SA/SD process:

1. Requirements gathering: The first step in the SA/SD process is to gather requirements from stakeholders,
including users, customers, and business partners.

2. Structured Analysis: During the Structured Analysis phase, the requirements are analyzed to identify the
major components of the system, the relationships between those components, and the data flows
within the system.

3. Data Modeling: During this phase, a data model is created to represent the data used in the system and
the relationships between data elements.

4. Process Modeling: During this phase, the processes within the system are modeled using flowcharts and
data flow diagrams.

5. Input/Output Design: During this phase, the inputs and outputs of the system are designed, including the
user interface and reports.

6. Structured Design: During the Structured Design phase, the system is designed to meet the requirements
gathered in the Structured Analysis phase. This may include selecting appropriate hardware and software
platforms, designing databases, and defining data structures.

7. Implementation and Testing: Once the design is complete, the system is implemented and tested.

SA/SD has been largely replaced by more modern software development methodologies, but its principles of
structured analysis and design continue to influence current software development practices. The method is
known for its focus on breaking down complex systems into smaller components, which makes it easier to
understand and manage the system as a whole.

Basically, the approach of SA/SD is based on the Data Flow Diagram. It is easy to understand SA/SD but it focuses
on well-defined system boundary whereas the JSD approach is too complex and does not have any graphical
representation.

SA/SD is combined known as SAD and it mainly focuses on the following 3 points:

1. System

2. Process
19 | P a g e
 3. Technology

SA/SD involves 2 phases:

1. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition diagram and ER diagram.

2. Design Phase: It uses Structure Chart and Pseudo Code.

1. Analysis Phase:

Analysis Phase involves data flow diagram, data dictionary, state transition diagram, and entity-relationship
diagram.

1. Data Flow Diagram:

In the data flow diagram, the model describes how the data flows through the system. We can
incorporate the Boolean operators and & or link data flow when more than one data flow may be input or
output from a process.

For example, if we have to choose between two paths of a process we can add an operator or and if two data
flows are necessary for a process we can add an operator. The input of the process “check-order” needs the credit
information and order information whereas the output of the process would be a cash-order or a good-credit-
order.

2. Data Dictionary:
The content that is not described in the DFD is described in the data dictionary. It defines the data store
and relevant meaning. A physical data dictionary for data elements that flow between processes,
between entities, and between processes and entities may be included. This would also include
descriptions of data elements that flow external to the data stores.

A logical data dictionary may also be included for each such data element. All system names, whether they are
names of entities, types, relations, attributes, or services, should be entered in the dictionary.

3. State Transition Diagram:

State transition diagram is similar to the dynamic model. It specifies how much time the function will take
to execute and data access triggered by events. It also describes all of the states that an object can have,
the events under which an object changes state, the conditions that must be fulfilled before the transition
will occur and the activities were undertaken during the life of an object.

4. ER Diagram:
ER diagram specifies the relationship between data store. It is basically used in database design. It
basically describes the relationship between different entities.

2. Design Phase:

Design Phase involves structure chart and pseudocode.

1. Structure Chart:
It is created by the data flow diagram. Structure Chart specifies how DFS’s processes are grouped into
tasks and allocated to the CPU. The structured chart does not show the working and internal structure of
the processes or modules and does not show the relationship between data or data flows. Similar to

20 | P a g e
 other SASD tools, it is time and cost-independent and there is no error-checking technique associated
with this tool. The modules of a structured chart are arranged arbitrarily and any process from a DFD can
be chosen as the central transform depending on the analysts’ own perception. The structured chart is
difficult to amend, verify, maintain, and check for completeness and consistency.

2. Pseudo Code: It is the actual implementation of the system. It is an informal way of programming that
doesn’t require any specific programming language or technology.

Advantages of Structured Analysis and Structured Design (SA/SD):

1. Clarity and Simplicity: The SA/SD method emphasizes breaking down complex systems into smaller, more
manageable components, which makes the system easier to understand and manage.

2. Better Communication: The SA/SD method provides a common language and framework for
communicating the design of a system, which can improve communication between stakeholders and
help ensure that the system meets their needs and expectations.

3. Improved maintainability: The SA/SD method provides a clear, organized structure for a system, which
can make it easier to maintain and update the system over time.

4. Better Testability: The SA/SD method provides a clear definition of the inputs and outputs of a system,
which makes it easier to test the system and ensure that it meets its requirements.

Disadvantages of Structured Analysis and Structured Design (SA/SD):

1. Time-Consuming: The SA/SD method can be time-consuming, especially for large and complex systems, as
it requires a significant amount of documentation and analysis.

2. Inflexibility: Once a system has been designed using the SA/SD method, it can be difficult to make changes
to the design, as the process is highly structured and documentation-intensive.

3. Limited Iteration: The SA/SD method is not well-suited for iterative development, as it is designed to be
completed in a single pass.

System Design Strategy – Software Engineering

A good system design is to organize the program modules in such a way that are easy to develop and change.
Structured design techniques help developers to deal with the size and complexity of programs. Analysts create
instructions for the developers about how code should be written and how pieces of code should fit together to
form a program.

Software Engineering is the process of designing, building, testing, and maintaining software. The goal of software
engineering is to create software that is reliable, efficient, and easy to maintain. System design is a critical
component of software engineering and involves making decisions about the architecture, components, modules,
interfaces, and data for a software system.

System Design Strategy refers to the approach that is taken to design a software system. There are several
strategies that can be used to design software systems, including the following:

1. Top-Down Design: This strategy starts with a high-level view of the system and gradually breaks it down
into smaller, more manageable components.

2. Bottom-Up Design: This strategy starts with individual components and builds the system up, piece by
piece.

21 | P a g e
 3. Iterative Design: This strategy involves designing and implementing the system in stages, with each stage
building on the results of the previous stage.

4. Incremental Design: This strategy involves designing and implementing a small part of the system at a
time, adding more functionality with each iteration.

5. Agile Design: This strategy involves a flexible, iterative approach to design, where requirements and
design evolve through collaboration between self-organizing and cross-functional teams.

The design of a system is essentially a blueprint or a plan for a solution for the system. The design process for
software systems often has two levels. At the first level the focus is on deciding which modules are needed for the
system, the specifications of these modules and how the modules should be interconnected. The design of a
system is correct if a system built precisely according to the design satisfies the requirements of that system. The
goal of the design process is not simply to produce a design for the system. Instead, the goal is to find the best
possible design within the limitations imposed by the requirements and the physical and social environment in
which the system will operate.

The choice of system design strategy will depend on the particular requirements of the software system, the size
and complexity of the system, and the development methodology being used. A well-designed system can
simplify the development process, improve the quality of the software, and make the software easier to maintain.

Importance of System Design Strategy:

1. If any pre-existing code needs to be understood, organized, and pieced together.

2. It is common for the project team to have to write some code and produce original programs that support
the application logic of the system.

Understanding these strategies allows developers to create scalable, maintainable systems that meet user
requirements. For a comprehensive understanding of system design principles, the System Design Course is an
excellent resource that delves into effective design methodologies and practices.

There are many strategies or techniques for performing system design. They are:

Bottom-up approach:

The design starts with the lowest level components and subsystems. By using these components, the next
immediate higher-level components and subsystems are created or composed. The process is continued till all the
components and subsystems are composed into a single component, which is considered as the complete system.
The amount of abstraction grows high as the design moves to more high levels.

By using the basic information existing system, when a new system needs to be created, the bottom-up strategy
suits the purpose.

22 | P a g e
Bottom-up approach

Advantages of Bottom-up approach:

 The economics can result when general solutions can be reused.

 It can be used to hide the low-level details of implementation and be merged with the top-down
technique.

Disadvantages of Bottom-up approach:

 It is not so closely related to the structure of the problem.

 High-quality bottom-up solutions are very hard to construct.

 It leads to the proliferation of ‘potentially useful’ functions rather than the most appropriate ones.

Top-down approach:

Each system is divided into several subsystems and components. Each of the subsystems is further divided into a
set of subsystems and components. This process of division facilitates forming a system hierarchy structure. The
complete software system is considered a single entity and in relation to the characteristics, the system is split
into sub-systems and components. The same is done with each of the sub-systems.

This process is continued until the lowest level of the system is reached. The design is started initially by defining
the system as a whole and then keeps on adding definitions of the subsystems and components. When all the
definitions are combined, it turns out to be a complete system.

For the solutions of the software that need to be developed from the ground level, a top-down design best suits
the purpose.

23 | P a g e
Top-down approach

Advantages of Top-down approach:

 The main advantage of the top-down approach is that its strong focus on requirements helps to make a
design responsive according to its requirements.

Disadvantages of Top-down approach:

 Project and system boundaries tend to be application specification-oriented. Thus, it is more likely that
the advantages of component reuse will be missed.

 The system is likely to miss, the benefits of a well-structured, simple architecture.

 Hybrid Design:
It is a combination of both top-down and bottom-up design strategies. In this, we can reuse the modules.

Advantages of using a System Design Strategy:

1. Improved quality: A well-designed system can improve the overall quality of the software, as it provides a
clear and organized structure for the software.

2. Ease of maintenance: A well-designed system can make it easier to maintain and update the software, as
the design provides a clear and organized structure for the software.

3. Improved efficiency: A well-designed system can make the software more efficient, as it provides a clear
and organized structure for the software that reduces the complexity of the code.

4. Better communication: A well-designed system can improve communication between stakeholders, as it

provides a clear and organized structure for the software that makes it easier for stakeholders to
understand and agree on the design of the software.

5. Faster development: A well-designed system can speed up the development process, as it provides a clear
and organized structure for the software that makes it easier for developers to understand the
requirements and implement the software.

Disadvantages of using a System Design Strategy:

1. Time-consuming: Designing a system can be time-consuming, especially for large and complex systems, as
it requires a significant amount of documentation and analysis.

2. Inflexibility: Once a system has been designed, it can be difficult to make changes to the design, as the
process is often highly structured and documentation-intensive.

Database Sharding – System Design

What is Sharding?

Let’s understand sharding with the help of an example:

You get the pizza in different slices and you share these slices with your friends. Sharding which is also known as
data partitioning works on the same concept of sharing the Pizza slices.

24 | P a g e
It is basically a database architecture pattern in which we split a large dataset into smaller chunks (logical shards)
and we store/distribute these chunks in different machines/database nodes (physical shards).

 Each chunk/partition is known as a “shard” and each shard has the same database schema as the original
database.

 We distribute the data in such a way that each row appears in exactly one shard.

 It’s a good mechanism to improve the scalability of an application.

Methods of Sharding

1. Key Based Sharding

This technique is also known as hash-based sharding. Here, we take the value of an entity such as customer ID,
customer email, IP address of a client, zip code, etc and we use this value as an input of the hash function. This
process generates a hash value which is used to determine which shard we need to use to store the data.

 We need to keep in mind that the values entered into the hash function should all come from the same
column (shard key) just to ensure that data is placed in the correct order and in a consistent manner.

 Basically, shard keys act like a primary key or a unique identifier for individual rows.

For example:

You have 3 database servers and each request has an application id which is incremented by 1 every time a new
application is registered.

To determine which server data should be placed on, we perform a modulo operation on these applications id
with the number 3. Then the remainder is used to identify the server to store our data.

25 | P a g e
Advantages of Key Based Sharding:

 Predictable Data Distribution:

o Key-based sharding provides a predictable way to distribute data across shards.

o Every distinct key value is associated with a particular shard, guaranteeing a uniform and
consistent distribution of data.

 Optimized Range Queries:

o If queries involve ranges of key values, key-based sharding can be optimized to handle these
range queries efficiently.

o This is especially beneficial when dealing with operations that span a range of consecutive key
values.

Disadvantages of Key Based Sharding:

 Uneven Data Distribution: If the sharding key is not well-distributed it may result in uneven data
distribution across shards

 Limited Scalability with Specific Keys: The scalability of key-based sharding may be limited if certain keys
experience high traffic or if the dataset is heavily skewed toward specific key ranges.

 Complex Key Selection: Selecting an appropriate sharding key is crucial for effective key-based sharding.

2. Horizontal or Range Based Sharding

In this method, we divide the data by separating it into different parts based on the range of a specific value
within each record. Let’s say you have a database of your online customers’ names and email information. You
can split this information into two shards.

 In one shard you can keep the info of customers whose first name starts with A-P

 In another shard, keep the information of the rest of the customers.

26 | P a g e
Advantages of Range Based Sharding:

 Scalability: Horizontal or range-based sharding allows for seamless scalability by distributing data across
multiple shards, accommodating growing datasets.

 Improved Performance: Data distribution among shards enhances query performance through
parallelization, ensuring faster operations with smaller subsets of data handled by each shard.

Disadvantages of Range Based Sharding:

 Complex Querying Across Shards: Coordinating queries involving multiple shards can be challenging.

 Uneven Data Distribution: Poorly managed data distribution may lead to uneven workloads among
shards.

3. Vertical Sharding

In this method, we split the entire column from the table and we put those columns into new distinct tables. Data
is totally independent of one partition to the other ones. Also, each partition holds both distinct rows and
columns. We can split different features of an entity in different shards on different machines.

For example:

On Twitter users might have a profile, number of followers, and some tweets posted by his/her own. We can place
the user profiles on one shard, followers in the second shard, and tweets on a third shard.

Advantages of Vertical Sharding:

27 | P a g e
  Query Performance: Vertical sharding can improve query performance by allowing each shard to focus on
a specific subset of columns. This specialization enhances the efficiency of queries that involve only a
subset of the available columns.

 Simplified Queries: Queries that require a specific set of columns can be simplified, as they only need to
interact with the shard containing the relevant columns.

Disadvantages of Vertical Sharding:

 Potential for Hotspots: Certain shards may become hotspots if they contain highly accessed columns,
leading to uneven distribution of workloads.

 Challenges in Schema Changes: Making changes to the schema, such as adding or removing columns,
may be more challenging in a vertically sharded system. Changes can impact multiple shards and require
careful coordination.

4. Directory-Based Sharding

In this method, we create and maintain a lookup service or lookup table for the original database. Basically we
use a shard key for lookup table and we do mapping for each entity that exists in the database. This way we keep
track of which database shards hold which data.

The lookup table holds a static set of information about where specific data can be found. In the above image,
you can see that we have used the delivery zone as a shard key:

 Firstly the client application queries the lookup service to find out the shard (database partition) on which
the data is placed.

 When the lookup service returns the shard it queries/updates that shard.

Advantages of Directory-Based Sharding:

 Flexible Data Distribution: Directory-based sharding allows for flexible data distribution, where the
central directory can dynamically manage and update the mapping of data to shard locations.

 Efficient Query Routing: Queries can be efficiently routed to the appropriate shard using the information
stored in the directory. This results in improved query performance.

 Dynamic Scalability: The system can dynamically scale by adding or removing shards without requiring
changes to the application logic.

Disadvantages of Directory-Based Sharding:

28 | P a g e
  Centralized Point of Failure: The central directory represents a single point of failure. If the directory
becomes unavailable or experiences issues, it can disrupt the entire system, impacting data access and
query routing.

 Increased Latency: Query routing through a central directory introduces an additional layer, potentially
leading to increased latency compared to other sharding strategies.

Ways optimize database sharding for even data distribution

Here are some simple ways to optimize database sharding for even data distribution:

 Use Consistent Hashing: This helps distribute data more evenly across all shards by using a hashing
function that assigns records to different shards based on their key values.

 Choose a Good Sharding Key: Picking a well-balanced sharding key is crucial. A key that doesn’t create
hotspots ensures that data spreads out evenly across all servers.

 Range-Based Sharding with Caution: If using range-based sharding, make sure the ranges are properly
defined so that one shard doesn’t get overloaded with more data than others.

 Regularly Monitor and Rebalance: Keep an eye on data distribution and rebalance shards when
necessary to avoid uneven loads as data grows.

 Automate Sharding Logic: Implement automation tools or built-in database features that automatically
distribute data and handle sharding to maintain balance across shards.

Alternatives to database sharding

Below are some of the alternatives to database sharding:

1. Vertical Scaling: Instead of splitting the database, you can upgrade your existing server by adding more
CPU, memory, or storage to handle more load. However, this has limits as you can only scale a server so
much.

2. Replication: You can create copies of your database on multiple servers. This helps with load balancing
and ensures availability, but can lead to synchronization issues between replicas.

3. Partitioning: Instead of sharding across multiple servers, partitioning splits data within the same server. It
divides data into smaller sections, improving query performance for large datasets.

4. Caching: By storing frequently accessed data in a cache (like Redis or Memcached), you reduce the load
on your main database, improving performance without needing to shard.

5. CDNs: For read-heavy workloads, using a Content Delivery Network (CDN) can offload some of the data
access from your primary database, reducing the need for sharding.

Advantages of Sharding in System Design

Sharding offers many advantages in system design such as:

1. Enhances Performance: By distributing the load among several servers, each server can handle less work,
which leads to quicker response times and better performance all around.

2. Scalability: Sharding makes it easier to scale as your data grows. You can add more servers to manage the
increased data load without affecting the system’s performance.

29 | P a g e
 3. Improved Resource Utilization: When data is dispersed, fewer servers are used, reducing the possibility
of overloading one server.

4. Fault Isolation: If one shard (or server) fails, it doesn’t take down the entire system, which helps in better
fault isolation.

5. Cost Efficiency: You can use smaller, cheaper servers instead of investing in a large, expensive one. As the
system grows, sharding helps keep costs in control.

Disadvantages of Sharding in System Design

Sharding comes with some disadvantages in system design such as:

1. Increased Complexity: Managing and maintaining multiple shards is more complex than working with a
single database. It requires careful planning and management.

2. Rebalancing Challenges: If data distribution becomes uneven, rebalancing shards (moving data between
servers) can be difficult and time-consuming.

3. Cross-Shard Queries: Queries that need data from multiple shards can be slower and more complicated
to handle, affecting performance.

4. Operational Overhead: With sharding, you’ll need more monitoring, backups, and maintenance, which
increases operational overhead.

5. Potential Data Loss: If a shard fails and isn’t properly backed up, there’s a higher risk of losing the data
stored on that shard.

Conclusion

Sharding is a great solution when the single database of your application is not capable to handle/store a huge
amount of growing data. Sharding helps to scale the database and improve the performance of the application.
However, it also adds some complexity to your system. The above methods and architectures have clearly shown
the benefits and drawbacks of each sharding technique.

Horizontal and Vertical Scaling | System Design

What is Scalabilty?

Scalability refers to the ability of a system to handle increasing amounts of workload or requests without
sacrificing performance or incurring excessive costs. It’s crucial to understand scalability in system design because
it directly impacts the system’s ability to grow and adapt to changing requirements over time. Failing to design for
scalability can lead to bottlenecks, performance issues, and ultimately, system failures as demand increases.

There are two main types of scalability: Vertical scaling or Scale-up and Horizontal scaling or Scale-out

What is Vertical Scaling?

Vertical scaling, also known as scaling up, refers to the process of increasing the capacity or capabilities of an
individual hardware or software component within a system.

 You can add more power to your machine by adding better processors, increasing RAM, or other power-
increasing adjustments.

30 | P a g e
  Vertical scaling aims to improve the performance and capacity of the system to handle higher loads or
more complex tasks without changing the fundamental architecture or adding additional servers.

For Example:

Imagine you have a computer at home that you use for various tasks such as web browsing, word processing, and
light gaming. Over time, you find that your computer struggles to keep up with more resource-intensive tasks like
video editing or running advanced software.

 To address this issue, you decide to upgrade your existing computer by adding more powerful
components such as a faster processor, additional RAM, or a larger hard drive.

 By doing so, you’re vertically scaling your system, increasing its capacity to handle more demanding tasks.

Characteristics of the Vertical Scaling

 This approach is also known as the ‘scale-up‘ approach.

 It doesn’t require any partitioning of data and all the traffic resides on a single node with more resources.

 Its implementation is easy.

 Less administrative effort as you need to manage just one system.

 Application compatibility is maintained.

 Mostly used in small and mid-sized companies.

 MySQL and Amazon RDS is a good examples of vertical scaling.

Adavantages and Disadvantages of Vertical Scaling

Below are the Adavantages and Disadvantages of Vertical Scaling:

 Advantages of vertical scaling

o Increased capacity: A server’s performance and ability to manage incoming requests can both be
enhanced by upgrading its hardware.

o Easier management: Upgrading a single node is usually the focus of vertical scaling, which might
be simpler than maintaining several nodes.
31 | P a g e
  Disadvantages of vertical scaling:

o Limited scalability: While horizontal scaling can be readily extended by adding more nodes and
vertical scaling is constrained by the hardware’s physical limitations.

o Increased cost: It may be more costly to upgrade a server’s hardware than to add extra nodes.

o Single point of failure: One server still receives all incoming requests thus increasing the
possibility of downtime in the event of a server failure.

What is Horizontal Scaling?

Horizontal scaling, also known as scaling out, refers to the process of increasing the capacity or performance of a
system by adding more machines or servers to distribute the workload across a larger number of individual units.

 In this approach, there is no need to change the capacity of the server or replace the server.

 Also, like vertical scaling, there is no downtime while adding more servers to the network.

For Example:

Imagine you own a small delivery service company that initially operates with a single delivery van. As your
business grows, you start receiving more orders and delivering to a larger area. However, you quickly realize that
the single van is not sufficient to handle the increasing demand efficiently.

 To address this issue, you decide to horizontally scale your delivery operation by adding more delivery
vehicles to your fleet. Instead of relying on just one van, you purchase several additional vans and hire
more drivers.

 By doing so, you’re able to distribute the workload across multiple vehicles, enabling your company to
handle a greater volume of packages and serve a larger customer base.

Note: Most organizations choose this approach because it includes increasing I/O concurrency, reducing the load
on existing nodes, and increasing disk capacity. This approach is the best solution for projects which have
requirements for high availability or failover.

Characteristics of the horizontal scaling

 This approach is also known as the ‘scale-out’ approach.

 Horizontal scalability can be achieved with the help of a distributed file system, clustering, and load–
balancing.

32 | P a g e
  Traffic can be managed effectively.

 Easier to run fault tolerance.

 Easy to upgrade.

 Easy to size and resize according to your needs.

 Implementation cost is less expensive compared to scaling up.

 Google with its Gmail and YouTube, Yahoo, Facebook, eBay, Amazon, etc. are heavily utilizing horizontal
scaling.

 Cassandra and MongoDB are good examples of horizontal scaling.

Adavantages and Disadvantages of Horizontal Scaling

Below are the Adavantages and Disadvantages of horizontal Scaling:

 Advantages of horizontal scaling

o Increased capacity: More nodes or instances can handle a larger number of incoming requests.

o Improved performance: By distributing the load over several nodes or instances, it is less likely
that any one server will get overloaded.

o Increased fault tolerance: Incoming requests can be sent to another node in the event of a node
failure, lowering the possibility of downtime.

 Disadvantages of horizontal scaling

o Increased complexity: Managing multiple nodes or instances can be more complex than
managing a single node.

o Increased cost: Adding more nodes or instances will typically increase the cost of the system.

Differences between Horizontal and Vertical Scaling

We have understood the meaning of both the major categories of scaling an application. We also have discussed
some pros and cons of each one of them. Let’s do a quick comparison of these two approaches based on these
pros and cons.
33 | P a g e
Aspect Horizontal Scaling Vertical Scaling

Adds more machines or servers to

Resource Addition Enhances resources of individual components
distribute workload

Generally more cost-effective for Initially simpler, but can become costlier long-
Cost Effectiveness
large-scale systems term

Offers greater flexibility as it’s easier

Flexibility Limited flexibility, especially with hardware
to add units

Enhances fault tolerance by Limited fault tolerance as it relies on a single

Fault Tolerance
distributing workload unit

Performance can improve as Performance may improve, but can hit hardware
Performance
workload is distributed limits

Single Point of
Less prone to single points of failure Potential single points of failure due to one unit
Failure

Can introduce complexity in Simpler to manage as it involves fewer

Complexity
managing distributed system components

Ideal for handling massive scalability

Applicability Suitable for moderate scalability requirements
needs

Requires load balancing

mechanisms to distribute Load balancing may be less critical as workload
Load Balancing
workload evenly across multiple is managed by a single unit in most cases
units

Vertical scaling primarily involves interprocess

Horizontal scaling relies heavily
communication within a single machine or
Machine on network communication to
between
Communication coordinate tasks and share data
closely coupled processes, minimizing the need
between distributed machines
for network communication

Which scaling option is right for an application?

34 | P a g e
After a fair understanding of both options, we can see that both of them have some pros and cons. There will be
always some tradeoffs so it may be a little bit trickier for developers to decide which one is better for an
application. You need to make a smart decision here.

 Firstly, you should identify your requirements, business goals, and areas where we would like to add
value.

 Then make important design decisions by questioning ourselves, developing prototypes, and refining the
design.

Certain factors are important to consider for a better understanding of your business goal or requirement. Such as:

 Performance requirements or performance characteristics of an application.

 System throughput

 System response time

 System availability requirement

 Is the system fault-tolerant? If so, what is the degree of it?

 Is the design reliable?

 What level of consistency do we care about?

 What’s the scalability goal of the application (you might have some short-term or immediate one’s goal,
but what is going to happen in the long run ?)

All the above factors will help you to identify the business goal and requirements for your application. Whatever
option you choose, it should ideally be able to answer the above and many other similar questions.

 You should have a clear understanding of the differences between these 2 scaling approaches. Identify
what suits your requirements, and see if the application really fits the model you choose.

 Most of the time in big organizations engineers take some good qualities of vertical scaling and some
good qualities of horizontal scaling.

 They follow the hybrid approach of combining the speed and consistency of vertical scaling, with the
resilience and infinite scalability of horizontal scaling.

When to Use Vertical Scaling

Use Vertical Scaling when:

 When you need to enhance a single server’s performance by adding more resources (CPU, RAM, storage).

 Ideal for applications that require significant processing power.

 Easier to implement since it involves upgrading existing hardware rather than managing multiple servers.

When to Use Horizontal Scaling

Use Horizontal Scaling when:

 When you need to manage growing demands by adding more servers or nodes.

 Best for applications designed to operate across multiple servers for better performance.

35 | P a g e
  Provides redundancy and minimizes the risk of a single point of failure.

 Effective for applications with variable demand, allowing for flexible scaling.

Load Balancer – System Design

When a website becomes extremely popular, the traffic on that website increases, and the load on a single server
also increases. The concurrent traffic overloads the single server and the website becomes slower for the users.
To meet the request of these high volumes of data and to return the correct response in a fast and reliable
manner, we need to scale the server. This can be done by adding more servers to the network and distributing all
the requests across these servers.

Important Topics for the Load Balancer – System Design Interview Question

1. What is a Load Balancer?

2. What will happen if there is No Load Balancer?
3. How Load Balancer Works?
4. Where Are Load Balancers Typically Placed?
5. Types of Load Balancers
6. Load Balancing Algorithms
7. How to Use Load Balancing During System Design Interviews?
1. What is a Load Balancer?

A load balancer is a networking device or software application that distributes and balances the incoming traffic
among the servers to provide high availability, efficient utilization of servers, and high performance.

This article outlines various strategies for implementing load balancing and its importance in high-availability
systems. To build a solid foundation in system design, the System Design Course will help you understand the
underlying principles and techniques for designing robust and scalable systems.

 Load balancers are highly used in cloud computing domains, data centers, and large-scale web
applications where traffic flow needs to be managed.

 The primary goal of using a load balancer is, not to overburden with huge incoming traffic which may lead
to server crashes or high latency.

2. What will happen if there is No Load Balancer?

Before understanding how a load balancer works, let’s understand what problem will occur without the load
balancer through an example.

Consider a scenario where an application is running on a single server and the client connects to that server
directly without load balancing.

36 | P a g e
There are two main problems with this model:

 Single Point of Failure:

o If the server goes down or something happens to the server the whole application will be
interrupted and it will become unavailable for the users for a certain period. It will create a bad
experience for users which is unacceptable for service providers.

 Overloaded Servers:

o There will be a limitation on the number of requests that a web server can handle. If the business
grows and the number of requests increases the server will be overloaded.

o To solve the increasing number of requests we need to add a few more servers and we need to
distribute the requests to the cluster of servers.

3. How Load Balancer Works?

Lets understand how Load Balancer works through the above discussed example:

To solve the above issue and to distribute the number of requests we can add a load balancer in front of the web
servers and allow our services to handle any number of requests by adding any number of web servers in the
network.

 We can spread the request across multiple servers.

 For some reason, if one of the servers goes offline the service will be continued.

 Also, the latency on each request will go down because each server is not bottlenecked on RAM/Disk/CPU
anymore.

37 | P a g e
Load balancers minimize server response time and maximize throughput. Load balancer ensures high availability
and reliability by sending requests only to online servers Load balancers do continuous health checks to monitor
the server’s capability of handling the request. Depending on the number of requests or demand load balancers
add or remove the number of servers.

4. Where Are Load Balancers Typically Placed?

Below is the image where a load balancer can be placed…

 In between the client application/user and the server

 In between the server and the application/job servers
 In between the application servers and the cache servers
 In between the cache servers the database servers

5. Types of Load Balancers

5.1. Types of Load Balancer – Based on Configurations

There are mainly three typers of load balancers based on configurations:

1. Software Load Balancers

Software load balancers are applications or components that run on general-purpose servers. They are
implemented in software, making them flexible and adaptable to various environments.

2. Hardware Load Balancers

38 | P a g e
As the name suggests we use a physical appliance to distribute the traffic across the cluster of network servers.
These load balancers are also known as Layer 4-7 Routers and these are capable of handling all kinds of HTTP,
HTTPS, TCP, and UDP traffic.

 These load balancers are expensive to acquire and configure, which is the reason a lot of service providers
use them only as the first entry point for user requests.

 Later the internal software load balancers are used to redirect the data behind the infrastructure wall.

3. Virtual Load Balancers

A virtual load balancer is a type of load balancing solution implemented as a virtual machine (VM) or software
instance within a virtualized environment ,such as data centers utilizing virtualization technologies like VMware,
Hyper-V, or KVM.. It plays a crucial role in distributing incoming network traffic across multiple servers or
resources to ensure efficient utilization of resources, improve response times, and prevent server overload.

5.2. Types of Load Balancer – Based on Functions

There are mainly three typers of load balancers based on functions:

1. Layer 4 (L4) Load Balancer

Layer-4 load balancers operate at the transport layer of the OSI model. They make forwarding decisions based on
information available in network layer protocols (such as IP addresses and port numbers).

2. Layer 7 (L7) Load Balancer

Layer-7 load balancers operate at the application layer of the OSI model. They can make load balancing decisions
based on content, including information such as URLs, HTTP headers, or cookies.

3. Global Server Load Balancing (GSLB)

GSLB stands for Global Server Load Balancer. This type of load balancer goes beyond the traditional local load
balancing and is designed for distributing traffic across multiple data centers or geographically distributed servers.
It takes into account factors such as server proximity, server health, and geographic location to intelligently
distribute traffic across multiple locations.

Further Read: Layer-4 vs. Layer-7 vs. GSLB

6. Load Balancing Algorithms

We need a load-balancing algorithm to decide which request should be redirected to which backend
server. The different system uses different ways to select the servers from the load balancer. Companies
use varieties of load-balancing algorithm techniques depending on the configuration. Some of the
common load-balancing algorithms are given below:

39 | P a g e
1. Round Robin

The Round Robin algorithm is a simple static load balancing approach in which requests are distributed across the
servers in a sequential or rotational manner. It is easy to implement but it doesn’t consider the load already on a
server so there is a risk that one of the servers receives a lot of requests and becomes overloaded.

2. Weighted Round Robin

The Weighted Round Robin algorithm is also a static load balancing approach which is much similar to the round-
robin technique. The only difference is, that each of the resources in a list is provided a weighted
score. Depending on the weighted score the request is distributed to these servers.

3. Source IP Hash

The Source IP Hash cLoad Balancing Algorithm is a static method used in network load balancing to distribute
incoming requests among a set of servers based on the hash value of the source IP address. This algorithm aims to
ensure that requests originating from the same source IP address are consistently directed to the same server.

4. Least Connection Method

The Least Connections algorithm is a dynamic load balancing approach that assigns new requests to the server
with the fewest active connections. The idea is to distribute incoming workloads in a way that minimizes the
current load on each server, aiming for a balanced distribution of connections across all available resources.

5. Least Response Time Method

The Least Response method is a dynamic load balancing approach that aims to minimize response times by
directing new requests to the server with the quickest response time.

7. How to Use Load Balancing During System Design Interviews?

In your system design interview, you’ll be asked some sort of scalability question where you’ll have to explain how
load balancers help distribute the traffic and how it ensures scalability and availability of services in your
application. The overall concept that you need to keep in mind from this article is…

40 | P a g e
  A load balancer enables elastic scalability which improves the performance and throughput of data. It
allows you to keep many copies of data (redundancy) to ensure the availability of the system. In case a
server goes down or fails you’ll have the backup to restore the services.

 Load balancers can be placed at any software layer.

 Many companies use both hardware and software to implement load balancers, depending on the
different scale points in their system.

Routing requests through Load Balancer

What are Load Balancers?

In case multiple servers are present the incoming request coming to the system needs to be directed to one of
the multiple servers. We should ensure that every server gets an equal amount of requests. The requests must be
distributed in a uniform manner across all the servers. The component which is responsible for distributing these
incoming requests uniformly across the servers is known as Load Balancer. A Load Balancer acts as a layer
between the incoming requests coming from the user and multiple servers present in the system.

how routing requests through a load balancer works:

Incoming requests are received by the load balancer, which acts as a single point of entry for all incoming traffic.
The load balancer uses an algorithm to determine which server should handle the request, based on factors such
as the server’s current load, response time, and availability.
The load balancer forwards the request to the selected server.
The server processes the request and returns the response to the load balancer.
The load balancer returns the response to the client.
By routing requests through a load balancer, the system can improve its performance and capacity, as the load
balancer ensures that incoming requests are distributed evenly across all available servers. This helps to avoid
overloading any individual server and ensures that the system can continue to handle incoming requests even if
one or more servers fail.

41 | P a g e
In a distributed system architecture, routing requests through a load balancer is a common technique to improve
performance, scalability, and reliability. A load balancer acts as a traffic cop, distributing incoming requests across
multiple servers to balance the load and prevent any one server from becoming overloaded.

Here are some key points to understand about routing requests through a load balancer:

1. How it works: When a client sends a request to the system, it is first received by the load balancer. The
load balancer then distributes the request to one of several servers in the system based on a predefined
algorithm, such as round-robin, least connections, or IP hash. The server processes the request and sends
the response back to the client through the load balancer.

2. Load balancing algorithms: Load balancing algorithms are used by the load balancer to distribute requests
across servers. The choice of algorithm can affect the performance and reliability of the system. For
example, round-robin is a simple algorithm that evenly distributes requests across servers, while least
connections distributes requests to the server with the fewest active connections.

3. Scaling: Routing requests through a load balancer can help scale a system by allowing additional servers
to be added to handle increased traffic. When a new server is added, the load balancer can automatically
distribute requests to it.

4. High availability: Routing requests through a load balancer can also improve system reliability by
providing redundancy. If one server fails, the load balancer can automatically redirect requests to another
server.

The advantages of routing requests through a load balancer include:

1. Improved performance: By balancing the load across multiple servers, a load balancer can improve the
response time of a system and prevent any one server from becoming overloaded.

2. Increased scalability: A load balancer can help a system scale by allowing additional servers to be added
to handle increased traffic.

3. Improved reliability: A load balancer can improve the reliability of a system by providing redundancy and
automatically redirecting requests to healthy servers if one server fails.

4. Simplified management: A load balancer can simplify the management of a distributed system by allowing
administrators to configure and manage multiple servers through a single interface.

However, there are also some potential disadvantages to routing requests through a load balancer, including:

1. Cost: A load balancer can be expensive to implement and maintain, particularly for smaller systems.

2. Complexity: A load balancer can add additional complexity to a system, particularly when configuring and
managing multiple servers.

3. Single point of failure: A load balancer can be a single point of failure for a system. If the load balancer
fails, the entire system may become unavailable.

4. Overall, routing requests through a load balancer is a powerful technique for improving the performance,
scalability, and reliability of a distributed system. By understanding the key principles and potential
advantages and disadvantages, developers can make informed decisions about when and how to use load
balancing in their systems.

Latency and Throughput in System Design

42 | P a g e
Latency can be seen as the time it takes for data or a signal to travel from one point to another in a system. It
encompasses various delays, such as processing time, transmission time, and response time. Latency is a very
important topic for System Design. Performance optimization is a common topic in system design, Performance
Optimization is a part of Latency. In this article, we will discuss what is latency, how latency works, and How to
measure Latency, we will understand this with an example.

Important Topics for Latency and Throughput in System Design

 What is Latency?
 How does Latency works?
 Factors that causes High Latency
 How to measure Latency?
 Example for calculating the Latency
 Use Cases of Latency
 What is Throughput?
 Difference between Throughput and Latency (Throughput vs. Latency)
 Factors affecting Throughput
 Methods to improve Throughput
 FAQs for Latency and Throughput in System Design
o What is Latency?

Latency refers to the time it takes for a request to travel from its point of origin to its destination and receive a
response.

 Latency represents the delay between an action and its corresponding reaction

 It can be measured in various units like seconds, milliseconds, and nanoseconds depending on the system
and application.

What does it involve?

Latency involves so many things such as processing time, time to travel over the network between components,
and queuing time.

 Round Trip Time: This includes the time taken for the request to travel to the server, processing time at
the server, and the response time back to the sender.

43 | P a g e
  Different Components: Processing time, transmission time (over network or between components),
queueing time (waiting in line for processing), and even human reaction time can all contribue to overall
latency.

2. How does Latency works?

The time taken for each step—transmitting the action, server processing, transmitting the response, and updating
your screen—contributes to the overall latency.

Example: Let see an example when player in an online game firing a weapon.

 If your latency is high: You press “fire.”

 The command travels through the internet to the server, which takes time.

 The server processes the shot.

 The result travels back to your device.

 Your screen updates the result.

During this time, another player might have moved or shot you, but their actions haven’t reached your device yet
due to latency. This can result in what’s called “shot registration delay.” Your actions feel less immediate, and you
might see inconsistencies between what you’re seeing and what’s happening in the game world.

The working of Latency can be understood by two ways:

 Network Latency

 System Latency

2.1 What is Network Latency?

Network Latency is a type of Latency in system design, it refers to the time it takes for data to travel from one
point in a network to another.

We can take the example of email, think of it as the delay between hitting send on an email and the recipient
actually receiving it. Just like overall latency, it’s measured in milliseconds or even microseconds for real time
application.

Problem Statement:
44 | P a g e
Imagine sending a letter to a friend across the country. The time it takes from dropping the letter in the mailbox to
its arrival in your friends hand is analogus to network latency.

However, instead of physical transportation, data travels as packets through cables, routers, switches. Here is the
following ways

 Intiation: You click send on an email, triggering data packets information.

 Encapsulation: Data gets divided into packets with routing header and checksums.

 Transmission: Packets travel through various network devices like routers and switches.

 Processing: Each device checks headers, routes packets through the network, and adds some delay.

 Propagation: Data travels as electrical or light signals through cables or wireless frequencies.

 Destination: Packets reach your frinds computer, get reassembled, and the email content is displayed.

2.2 What is System Latency?

System latency refers to the overall time it takes for a request to go from its origin in the system to its destination
and receive a response

Think of Latency as the “wait time” in a system.

Problem Statement:

Clicking a button on a website, lets suppose login or SignUp button.

 User action: You click the button, sending a request to the web server.

 Processing: The server receives the request, processes it (database access, calculations, etc.).

 Response: The server generates a response and sends it back to your browser.

 Rendering: Your browser receives the response, parses it, and updates the webpage accordingly.

The time between clicking and seeing the updated webpage is the system latency. It includes processing time on
both client and server, network transfers, and rendering delays.

3. Factors that causes High Latency

High latency can severely impact the performance and user experience of distributed systems. Here are key
factors that contribute to high latency within this context:

1. Network Congestion:

 Explanation: High traffic on a network can cause delays as data packets queue up for
transmission.

 Example: A distributed system handling real-time financial transactions may experience high
latency during trading peaks due to network congestion.

2. Bandwidth Limitations:

 Explanation: Limited bandwidth can cause delays in data transmission, particularly in data-
intensive applications.

45 | P a g e
  Example: Video streaming services may experience buffering and high latency when bandwidth is
insufficient to handle the data load.

3. Geographical Distance:

 Explanation: Data traveling long distances between distributed nodes can increase latency due to
the inherent delays in transmission.

 Example: Cloud applications serving users from a single data center may face high latency for
users located far from that data center.

4. Inefficient Routing:

 Explanation: Suboptimal routing paths can increase the number of hops data must make, thus
increasing latency.

 Example: An application using outdated routing protocols might send data through several
unnecessary intermediate nodes, increasing response times.

5. Server Load:

 Explanation: Overloaded servers can take longer to process requests, contributing to high
latency.

 Example: E-commerce websites during a flash sale may face high server loads, resulting in slower
page loads and transaction times.

6. Serialization and Deserialization Overheads:

 Explanation: Converting data formats for transmission and reception can introduce delays.

 Example: A microservices architecture using JSON for inter-service communication may

experience high latency due to serialization/deserialization overheads.

7. Contention for Shared Resources:

 Explanation: Multiple processes competing for the same resources (e.g., CPU, memory, disk I/O)
can cause delays.

 Example: A distributed database with high contention for read/write operations might experience
increased latency.

8. Latency in Database Queries:

 Explanation: Complex or inefficient database queries can significantly increase response times.

 Example: A poorly indexed database query in a distributed system can take a long time to
execute, increasing overall latency.

4. How to measure Latency?

There are various ways to measure latency. Here are some common methods:

 Ping: This widely used tool sends data packets to a target server and measures the round-trip time
(RTT), providing an estimate of network latency between two points.

 Traceroute: This tool displays the path data packets take to reach a specific destination, revealing which
network hops contribute the most to overall latency.
46 | P a g e
  MTR (traceroute with ping): Combines traceroute and ping functionality, showing both routing
information and RTT at each hop along the path.

 Network monitoring tools: Dedicated network monitoring tools offer comprehensive analysis of network
performance, including latency metrics for different components and connections.

 Time stamps: Inserting time stamps at various points within a system’s code can measure the time it
takes for specific operations to occur, revealing bottlenecks and areas for optimization.

 Performance profiling tools: Specialized profiling tools track resource usage and execution times within a
system, providing detailed insights into system latency contributors.

 Application performance monitoring (APM) tools: Similar to network monitoring tools for
networks, APM tools monitor the performance of applications, including response times and latency
across various components.

Tips for accurate measurement:

 Repeat measurements: Latency can fluctuate due to various factors, so performing multiple
measurements and averaging the results can provide a more accurate picture.

 Control variables: Minimize external influences by controlling variables like network load or system
resource usage during measurements.

 Use appropriate tools: Choose tools specific to the type of latency you’re measuring and ensure they are
accurate and calibrated for your environment.

5. Example for calculating the Latency

5.1 Problem Statement

Calculate the round-trip time (RTT) latency for a data packet traveling between a client in New York City and a
server in London, UK, assuming a direct fiber-optic connection with a propagation speed of 200,000 km/s.

 Distance: Distance between NYC and London: 5570 km

 Propagation speed: 200,000 km/s

 Constraints: Assume no network congestion or processing delays.

 Desired Output: RTT latency in milliseconds.

5.2 Problem Statement

Calculate the average latency for a user clicking a button on a web application hosted on a server with a 5 ms
processing time. Assume a network latency of 20 ms between the user’s device and the server.

 Network latency: 20 ms

 Server processing time: 5 ms

 Constraints: Assume no additional processing delays on the client-side.

 Desired Output: Average latency in milliseconds.

6. Use Cases of Latency

6.1 Latency in Transactions

47 | P a g e
In the context of transactions, latency refers to the time it takes for a request (e.g., initiating a payment) to be
processed and the response (e.g., confirmation or completion) to be received. Steps Involved in this process are:

 Initiating Payment: You tap your phone to make a payment using Google Pay.

 Network Transmission: The payment request is sent to the payment processor through the Internet.

 Payment Processing: The processor verifies the transaction details and your account balance.

 Response Transmission: The result (approved or declined) is sent back to your phone.

 Confirmation Screen: Your phone displays the payment confirmation.

Example: Gpay, Paytm

Note: High latency here might cause a delay between your payment initiation and the confirmation on your
screen. However, the delay is usually short, especially for contactless payment systems designed for quick
transactions.

6.2 Latency in Gaming

In the context of gaming, latency refers to the delay between a player’s action and the corresponding response
they see on their screen. Let’s take the example of shooting a gun in an online shooter game:

Steps Involved:

 Player Action: You press the “fire” button to shoot your virtual gun.

 Network Transmission: The information about your action is sent to the game server via the internet.

 Server Processing: The game server receives your action, processes it, and determines the result (hit or
miss).

 Response Transmission: The result of your action is sent back to your device.

 Your Screen Update: Your device displays the outcome of your shot.

further read: High Latency vs Low Latency

7. What is Throughput?

Throughput generally refers to the rate at which a system, process, or network can transfer data or perform
operations in a given period of time. It is often measured in terms of bits per second (bps), bytes per second,
transactions per second, etc. It is calculated by taking a sum of number of operations/items processed divided by
the amount of time taken.

48 | P a g e
 For example, an ice-cream factory produces 50 ice-creams in an hour so the throughput of the factory is 50 ice-

creams/hour.

Here are a few contexts in which throughput is commonly used:

1. Network Throughput: In networking, throughput refers to the amount of data that can be transmitted
over a network in a given period. It’s an essential metric for evaluating the performance of
communication channels.

2. Disk Throughput: In storage systems, throughput measures how quickly data can be read from or written
to a storage device, usually expressed in terms of bytes per second.

3. Processing Throughput: In computing, especially in the context of CPUs or processors, throughput is the
number of operations completed in a unit of time. It could refer to the number of instructions executed
per second.

8. Difference between Throughput and Latency (Throughput vs. Latency)

Aspect Throughput Latency

The number of tasks completed in a given The time it takes for a single task to be
Definition time period. completed.

Typically measured in operations per Measured in time units such as

Measurement Unit second or transactions per second. milliseconds or seconds.

Inversely related to latency. Higher Inversely related to throughput. Lower

throughput often corresponds to lower latency often corresponds to higher
Relationship latency. throughput.

49 | P a g e
Aspect Throughput Latency

Low latency in gaming means minimal

A network with high throughput can
delay between user input and on-screen
transfer large amounts of data quickly.
Example action.

Reflects the overall system capacity and Reflects the responsiveness and perceived
ability to handle multiple tasks speed of the system from the user’s
Impact on System simultaneously. perspective.

9. Factors affecting Throughput

1. Network Congestion:

 High levels of traffic on a network can lead to congestion, reducing the available bandwidth and
impacting throughput.

 Solutions may include load balancing, traffic prioritization, and network optimization.

2. Bandwidth Limitations:

 The maximum capacity of the network or communication channel can constrain throughput.

 Upgrading to higher bandwidth connections can address this limitation.

3. Hardware Performance:

 The capabilities of routers, switches, and other networking equipment can influence throughput.

 Upgrading hardware or optimizing configurations may be necessary to improve performance.

4. Software Efficiency:

 Inefficient software design or poorly optimized algorithms can contribute to reduced throughput.

 Code optimization, caching strategies, and parallel processing can enhance software efficiency.

5. Protocol Overhead:

 Communication protocols introduce overhead, affecting the efficiency of data transmission.

 Choosing efficient protocols and minimizing unnecessary protocol layers can improve throughput.

6. Latency:

 High latency can impact throughput, especially in applications where real-time data processing is
crucial.

 Optimizing routing paths and using low-latency technologies can reduce delays.

7. Data Compression and Encryption:

 While compression can reduce the amount of data transmitted, it may introduce processing
overhead.

50 | P a g e
  Similarly, encryption algorithms can impact throughput, and balancing security needs with
performance is crucial.

10. Methods to improve Throughput

1. Network Optimization:

 Utilize efficient network protocols to minimize overhead.

 Implement Quality of Service (QoS) policies to prioritize critical traffic.

 Optimize routing algorithms to reduce latency and packet loss.

2. Load Balancing:

 Distribute network traffic evenly across multiple servers or paths.

 Prevents resource overutilization on specific nodes, improving overall throughput.

3. Hardware Upgrades:

 Upgrade network devices, such as routers, switches, and NICs, to higher-performing models.

 Ensure that servers and storage devices meet the demands of the workload.

4. Software Optimization:

 Optimize algorithms and code to reduce processing time.

 Minimize unnecessary computations and improve code efficiency.

5. Compression Techniques:

 Use data compression to reduce the amount of data transmitted over the network.

 Decreases the time required for data transfer, improving throughput.

6. Caching Strategies:

 Implement caching mechanisms to store and retrieve frequently used data locally.

 Reduces the need to fetch data from slower external sources, improving response times and
throughput.

7. Database Optimization:

 Optimize database queries and indexes to improve data retrieval times.

 Use connection pooling to efficiently manage database connections.

8. Concurrency Control:

 Employ effective concurrency control mechanisms to manage simultaneous access to resources.

 Avoid bottlenecks caused by contention for shared resources.

Conclusion

51 | P a g e
Thus, it can be said that latency is a pivotal factor in system design, which impacts user experience and the
performance of applications on a large scale. It’s essential to manage latency effectively, especially when scaling
systems, to ensure a responsive and seamless experience for users across various applications and services.

Object-Oriented Analysis and Design(OOAD)

Object-Oriented Analysis and Design (OOAD) is a way to design software by thinking of everything as objects
similar to real-life things. In OOAD, we first understand what the system needs to do, then identify key objects,
and finally decide how these objects will work together. This approach helps make software easier to manage,
reuse, and grow.

Table of Content

 What is Object-Oriented Analysis and Design(OOAD)?

 Important Aspects of OOAD

 Object-Oriented Analysis

 Object-Oriented Design

 Benefits of Object-Oriented Analysis and Design(OOAD)

 Challenges of Object-Oriented Analysis and Design(OOAD)

 Real world applications of Object-Oriented Analysis and Design(OOAD)

What is Object-Oriented Analysis and Design(OOAD)?

OOAD is based on the concepts of object-oriented programming (OOP) and is an organized and systematic
approach to designing and developing software systems. It is a software engineering paradigm that integrates two
distinct but closely related processes: Object-Oriented Analysis (OOA) and Object-Oriented Design (OOD).

Important Aspects of OOAD

Below are some important aspects of OOAD:

 Object-Oriented Programming: In this the real-world items are represented/mapped as software objects
with attributes and methods that relate to their actions.

 Design Patterns: Design patterns are used by OOAD to help developers in building software systems that
are more efficient and maintainable.

 UML Diagrams: UML diagrams are used in OOAD to represent the different components and interactions
of a software system.

 Use Cases: OOAD uses use cases to help developers understand the requirements of a system and to
design software systems that meet those requirements.

To enhance your skills in OOAD, the System Design Course offers practical insights and case studies that will help
you design better object-oriented systems.

Object-Oriented Analysis

Object-Oriented Analysis (OOA) is the process of understanding and analyzing the system requirements by looking
at the problem scenario in terms of objects.

 These objects represent real-world entities or concepts that are relevant to the system being developed.
52 | P a g e
  During OOA, the goal is to identify the objects, their attributes, behaviors, and relationships, without
focusing on how the system will be implemented.

For example: Lets say you’re building a game:

 OOA helps you figure out all the things you need to know about the game world – the characters, their
features, and how they interact.

 It’s like making a map of everything important.

 OOA also helps you understand what your game characters will do. It’s like writing down a script for each
character.

 Every program has specific tasks or jobs it needs to do. OOA helps you list and describe these jobs.

 In our game, it could be tasks like moving characters or keeping score. It’s like making a to-do list for your
software.

 OOA is smart about breaking things into different parts. It splits the job into three categories: things your
game knows, things your game does, and how things in your game behave.

Object-Oriented Design

In the object-oriented software development process, the analysis model, which is initially formed through
object-oriented analysis (OOA), undergoes a transformation during object-oriented design (OOD) i.e
implementation of the conceptual model developed in OOA. This evolution is crucial because it shapes the
analysis model into a detailed design model.

Furthermore, as part of the object-oriented design process, it is essential to define specific aspects:

 Data Organization of Attributes:

o OOD involves specifying how data attributes are organized within the objects.

o This includes determining the types of data each object will hold and how they relate to one
another.

 Procedural Description of Operations:

o OOD requires a procedural description for each operation that an object can perform.

o This involves detailing the steps or processes involved in carrying out specific tasks.

Below diagram shows a design pyramid for object-oriented systems. It is having the following four layers.

53 | P a g e
 1. The Subsystem Layer: It represents the subsystem that enables software to achieve user requirements
and implement technical frameworks that meet user needs.

2. The Class and Object Layer: It represents the class hierarchies that enable the system to develop using
generalization and specialization. This layer also represents each object.

3. The Message Layer: This layer deals with how objects interact with each other. It includes messages sent
between objects, method calls, and the flow of control within the system.

4. The Responsibilities Layer: It focuses on the responsibilities of individual objects. This includes defining
the behavior of each class, specifying what each object is responsible for, and how it responds to
messages.

Benefits of Object-Oriented Analysis and Design(OOAD)

 It increases the modularity and maintainability of software by encouraging the creation of tiny, reusable
parts that can be combined to create more complex systems.

 It provides a high-level, abstract representation of a software system, making understanding and

maintenance easier.

 It promotes object-oriented design principles and the reuse of objects, which lowers the amount of code
that must be produced and raises the quality of the program.

 Software engineers can use the same language and method that OOAD provides to communicate and
work together more successfully in groups.

 It can assist developers in creating scalable software systems that can adapt to changing user needs and
business demands over time.

Challenges of Object-Oriented Analysis and Design(OOAD)

 Because objects and their interactions need to be carefully explained and handled, it might complicate a
software system.

54 | P a g e
  Because objects must be instantiated, managed, and interacted with, this may result in additional
overhead and reduce the software’s speed.

 For beginner software engineers, OOAD might have a challenging learning curve since it requires a solid
grasp of OOP principles and methods.

 It can be a time-consuming process that involves significant upfront planning and documentation. This
can lead to longer development times and higher costs.

 OOAD can be more expensive than other software engineering methodologies due to the upfront
planning and documentation required.

Real world applications of Object-Oriented Analysis and Design(OOAD)

Some examples of OOAD’s practical uses are listed below:

 Banking Software: In banking systems, OOAD is frequently used to simulate complex financial
transactions, structures, and customer interactions. Designing adaptable and reliable financial apps is
made easier by OOAD’s modular and scalable architecture.

 Electronic Health Record (EHR) Systems: Patient data, medical records, and healthcare workflows are all
modeled using OOAD. Modular and flexible healthcare apps that may change to meet emerging
requirements can be made through object-oriented principles.

 Flight Control Systems: OOAD is crucial in designing flight control systems for aircraft. It helps model the
interactions between different components such as navigation systems, sensors, and control surfaces,
ensuring safety and reliability.

 Telecom Billing Systems: In the telecom sector, OOAD is used to model and build billing systems. It
enables the modular and scalable modeling of complex subscription plans, invoicing rules, and client data.

 Online Shopping Platforms: E-commerce system development frequently makes use of OOAD. Product
catalogs, user profiles, shopping carts, and payment procedures are all modeled, which facilitates
platform maintenance and functionality expansion.

Difference between Structured and Object-

Oriented Analysis
Structured and Object-Oriented Analysis are two distinct methodologies for software development. Structured
Analysis focuses on processes and data flow, while Object-Oriented Analysis emphasizes modeling entities and
their interactions. This article explores the key differences between these approaches and their implications for
system design and implementation.

Important Topics for Structured vs. Object-oriented Analysis

 What is Structured Analysis?

 What is Object-Oriented Analysis (OOA)?

 Structured vs. Object-oriented Analysis

 Advantages of Structured Analysis

 Disadvantages of Structured Analysis

55 | P a g e
  Advantages of Object-Oriented Analysis (OOA)

 Disadvantages of Object-Oriented Analysis (OOA)

 Use-cases of Structured Analysis

 Use-cases of Object-Oriented Analysis

 FAQs on Difference between Structured and Object-Oriented Analysis

What is Structured Analysis?

Structured Analysis is a methodology used in software engineering to understand and define system
requirements through a systematic approach. It focuses on breaking down a system into smaller, manageable
components and understanding the flow of data and processes.

 Key elements include data flow diagrams, process specifications, and data dictionaries, which help in
visualizing how data moves through the system and how different processes interact.

 The primary goal is to create a clear and detailed blueprint of the system before development begins.

What is Object-Oriented Analysis (OOA)?

Object-Oriented Analysis (OOA) is a methodology in software engineering that models a system based on real-
world entities and their interactions. It focuses on identifying objects—entities with both data (attributes) and
behaviors (methods)—and their relationships to design a system. The main components include classes, objects,
inheritance, and encapsulation. OOA emphasizes understanding and defining the system through these objects
and their interactions, which helps in creating a more modular, reusable, and maintainable system architecture.

In conclusion, Structured Analysis and OOA are both valuable software development methodologies, each with its
own strengths and weaknesses. The choice of which to use depends on the particular requirements and constraints
of a software project.

Understanding the differences between structured analysis and object-oriented analysis is vital for software
development, as each approach has its advantages and use cases. Dive into this System design course to learn
about these analysis techniques and their applications in real-world scenarios.

Structured vs. Object-oriented Analysis

Below are the differences between structures and object oriented analysis:

Structured Analysis Object-Oriented Analysis

The main focus is on the process and procedures of The main focus is on data structure and real-world
the system. objects that are important.

It uses System Development Life Cycle (SDLC)

methodology for different purposes like planning, It uses Incremental or Iterative methodology to refine
analyzing, designing, implementing, and supporting and extend our design.
an information system.

56 | P a g e
Structured Analysis Object-Oriented Analysis

It is suitable for well-defined projects with stable It is suitable for large projects with changing user
user requirements. requirements.

Risk while using this analysis technique is high and Risk while using this analysis technique is low and
reusability is also low. reusability is also high.

Structuring requirements include DFDs (Data Flow Requirement engineering includes the Use case model
Diagram), Structured Analysis, ER (Entity (find Use cases, Flow of events, Activity Diagram), the
Relationship) diagram, CFD (Control Flow Diagram), Object model (find Classes and class relations, Object
Data Dictionary, Decision table/tree, and the State interaction, Object to ER mapping), Statechart Diagram,
transition diagram. and deployment diagram.

This technique is old and is not preferred usually. This technique is new and is mostly preferred.

Advantages of Structured Analysis

Below are the advantages of structures analysis:

 Clear and straightforward: Structured Analysis is a clear and straightforward methodology that is easy to
understand and implement.

 Top-down approach: The top-down approach of Structured Analysis makes it easy to identify the high-
level functions and processes involved in a software system, and to break them down into smaller, more
manageable components.

 Emphasis on data: Structured Analysis places a strong emphasis on the data that a software system
manipulates, making it easier to understand the relationships between data and processes.

 Well-suited for small to medium-sized systems: Structured Analysis is well-suited for small to medium-
sized systems, where the focus is on breaking down complex systems into simpler, more manageable
components.

Disadvantages of Structured Analysis

Below are the disadvantages of structured analysis:

 Limited scalability: Structured Analysis is limited in its scalability, and may become cumbersome when
dealing with complex, large-scale systems.

 Lack of object orientation: Structured Analysis does not provide the object orientation and encapsulation
benefits of OOA, making it more difficult to manage and maintain large systems over time.

 Limited ability to model complex relationships: Structured Analysis has a limited ability to model
complex relationships between objects, making it less suitable for modeling large, complex systems.

Advantages of Object-Oriented Analysis (OOA)

Below are the advantages of object-oriented analysis(OOA):

57 | P a g e
  Reusable code: OOA enables the creation of reusable objects and design patterns, reducing the amount
of code that needs to be written and improving the quality and consistency of the software.

 Scalability: OOA is more scalable than Structured Analysis, making it better suited for large, complex
systems.

 Object orientation: OOA provides the benefits of object orientation, including encapsulation, inheritance,
and polymorphism, making it easier to manage and maintain large systems over time.

 Better modeling of complex relationships: OOA enables better modeling of complex relationships
between objects, making it better suited for modeling large, complex systems.

Disadvantages of Object-Oriented Analysis (OOA)

Below are the disadvantages of object oriented analysis(OOA):

 Steep learning curve: OOA can be more difficult to understand and implement than Structured Analysis,
especially for those who are not familiar with object-oriented programming.

 Bottom-up approach: The bottom-up approach of OOA can make it difficult to understand the high-level
functions and processes involved in a software system, and to break them down into smaller, more
manageable components.

 Emphasis on objects: OOA places a strong emphasis on objects, making it more difficult to understand
the relationships between data and processes.

Use-cases of Structured Analysis

Structured Analysis is particularly effective in scenarios where a clear, linear approach to understanding and
documenting system requirements is beneficial. Here are some common use cases:

 Legacy Systems Upgrades:

o When modernizing or enhancing older systems, Structured Analysis helps in detailing existing
processes and data flows, making it easier to understand and incrementally improve the system.

 Well-Defined Requirements:

o For projects with well-defined, stable requirements where processes are clear and unlikely to
change, Structured Analysis provides a straightforward method for modeling and documenting
system components.

 System Integration:

o In scenarios involving the integration of disparate systems, Structured Analysis helps in mapping
out data flows and processes, ensuring smooth integration by clearly defining how data should be
transferred and processed between systems.

 Regulatory Compliance:

o Projects requiring rigorous documentation for compliance with industry regulations benefit from
Structured Analysis, as it provides detailed process and data flow diagrams that can be used to
demonstrate adherence to standards.

Use-cases of Object-Oriented Analysis

58 | P a g e
Object-Oriented Analysis (OOA) is particularly advantageous in scenarios where flexibility, modularity, and reuse
are important. Here are some common use cases:

 Complex Systems Development:

o OOA is ideal for developing complex systems where modular design and reusable components
are needed. Its focus on objects and their interactions helps manage complexity more effectively.

 Software Reusability:

o Projects requiring reusable components benefit from OOA, as it promotes the creation of classes
and objects that can be easily reused across different parts of the system or in future projects.

 Rapid Prototyping:

o In environments where rapid development and iterative changes are required, OOA supports
quick adjustments and extensions by allowing changes to individual objects without disrupting
the entire system.

 Integration of New Technologies:

o When integrating new technologies or platforms, OOA helps by modeling systems in terms of
objects and their interactions, making it easier to adapt to new requirements or technologies.

Conclusion

In conclusion, Structured and Object-Oriented Analysis offer distinct approaches to system design and
implementation. Structured Analysis excels in defining processes and data flows, making it suitable for traditional
systems with well-defined requirements. In contrast, Object-Oriented Analysis provides a more flexible and
modular approach, ideal for complex systems that benefit from reusable and scalable design.

Unit-2
Scalability in System Design
What is Scalability and How to achieve it?

59 | P a g e
The ability of a system to accommodate a growing load or demand without compromising performance is
referred to as scalability. Scalability guarantees that systems can adjust without difficulty, whether a website’s
user base is growing or a corporation is extending its operations. Using distributed architectures like cloud
computing, code optimization, hardware enhancements, and other techniques are necessary to achieve
scalability.

Table of Content
 What is Scalability?
 Importance of Scalability in System Design
 How to achieve Scalability?
o Vertical Scaling
o Horizontal Scaling
 Vertical Scaling vs. Horizontal Scaling
 Factors Affecting Scalability
 Components that help to increase Scalabilty
 Real-World Examples of Scalable Systems
 Challenges and Trade-offs in Scalability
What is Scalability?
Scalability is the capacity of a system to support growth or to manage an increasing volume of work.
 When a system’s workload or scope rises, it should be able to maintain or even improve its performance,
efficiency, and dependability. This is known as scalability.
 A system must be scalable in order to accommodate growing user traffic, data volumes, or computing
demands without suffering a major performance hit or necessitating a total redesign.

Importance of Scalability in System Design

Scalability is a key factor in system design, offering many important benefits such as:
 Managing Growth: A system’s scalability lets it accommodate more users, more data, and more traffic
without compromising its dependability or performance. For companies who wish to expand over time
and attract more clients, this is essential.
 Increasing Performance: By dividing up the load among several servers or resources, a scalable system
increases overall performance. Better processing speed, quicker reaction times, and an easier-to-use ux
are the results of this.
 Ensuring Availability: Availability is ensured by scalability, which keeps systems operational even in the
event of unanticipated traffic spikes or component breakdowns. This is particularly crucial for mission-
critical systems that must always be operational to guarantee that consumers may get the services they
require.
 Cost-effectiveness: Systems that are scalable have the ability to modify their resources in response to
changes in demand, increasing or decreasing them as necessary. By employing only the necessary
resources, this flexibility helps prevent overprovisioning and results in significant cost savings.
 Encouraging Innovation: By reducing infrastructural barriers, scalability promotes the creation of new
features or services. Businesses can quickly adjust to changes in the market and maintain an advantage
over competitors due to this flexibility.
By prioritizing scalability in system design, businesses can ensure their applications and services remain fast,
reliable, and cost-effective, even as they grow and evolve.
How to achieve Scalability?
Now scalability is achieved via two methods in systems.
1. Vertical Scaling
Vertical scaling, also known as scaling up, refers to the process of increasing the capacity or capabilities of an
individual hardware or software component within a system.
 You can add more power to your machine by adding better processors, increasing RAM, or other power-
increasing adjustments.
 Vertical scaling aims to improve the performance and capacity of the system to handle higher loads or
more complex tasks without changing the fundamental architecture or adding additional servers.

Example of Vertical Scaling

Let’s say you have a web application running on a server with 4 CPU cores and 8GB of RAM.

60 | P a g e
As the application grows in popularity and starts receiving more traffic, you notice that the server is starting to
struggle to handle the increased load. To address this, you decide to vertically scale your server by upgrading it to
a new server with 8 CPU cores and 16GB of RAM.
Advantages of Vertical Scaling
1. Increased Capacity: You can greatly improve a server’s performance and capacity to handle more
requests by improving its hardware, for as by installing more RAM or a faster CPU.
2. Simplified Management: Since vertical scaling concentrates on improving a single server, it is simple to
implement. This can be less complicated and more user-friendly to handle than managing several servers.
Disadvantages of Vertical Scaling
1. Limited Scalability: The maximum hardware capacity of a single server places restrictions on vertical
scaling. Physical bounds are reached at a certain point in the vertical scaling process.
2. Increased Costs: Compared to adding many, less expensive servers, upgrading server hardware,
particularly with high-end components, might be more expensive. Because of this, choosing vertical
scaling may end up costing more in the long term.
3. Single Point of Failure: When one server is used, any incoming requests are impacted by its failure, which
causes downtime. Because of this, vertical scaling is more sensitive than horizontal scaling, which spreads
the load over a number of servers to lower the chance of a complete failure.
2. Horizontal Scaling
Horizontal scaling, also known as scaling out, refers to the process of increasing the capacity or performance of a
system by adding more machines or servers to distribute the workload across a larger number of individual units.
 In this approach, there is no need to change the capacity of the server or replace the server.
 Also, like vertical scaling, there is no downtime while adding more servers to the network

Example of Horizontal Scaling

Imagine you own a small delivery service company that initially operates with a single delivery van. As your
business grows, you start receiving more orders and delivering to a larger area. However, you quickly realize that
the single van is not sufficient to handle the increasing demand efficiently.
 To address this issue, you decide to horizontally scale your delivery operation by adding more delivery
vehicles to your fleet. Instead of relying on just one van, you purchase several additional vans and hire
more drivers.
 By doing so, you’re able to distribute the workload across multiple vehicles, enabling your company to
handle a greater volume of packages and serve a larger customer base.
Advantages of Horizontal Scaling
1. Expanded Capacity: By adding more servers or instances, horizontal scaling allows your system to handle
a larger number of incoming requests. This helps accommodate growing traffic and demand without
compromising performance.
2. Enhanced Performance: With multiple servers, the workload can be distributed evenly using load
balancing. This prevents any single server from becoming overloaded, ensuring smooth and efficient
performance across the system.
3. Greater Fault Tolerance: Horizontal scaling improves system reliability. If one server goes down, other
servers can take over the load, minimizing the risk of downtime and maintaining service availability.
Disadvantages of Horizontal Scaling
1. Increased Complexity: Managing a network of multiple servers or instances can be more challenging
compared to handling a single server. This requires robust infrastructure and management tools to
ensure everything runs smoothly.
2. Higher Costs: Adding more servers or instances generally increases the overall cost of the system. This
includes not just the hardware or cloud costs but also the expenses related to maintenance and
management of the additional resources.
Remember: Scalable code is generally computation inefficient. It is bitter truth because we split big and complex
code to a set of small associative operations so as to scale up horizontally because vertical scaling has a limit.
Vertical Scaling vs. Horizontal Scaling
Now that we have looked into the details of each type of scaling, let us compare them with respect to different
parameters:

61 | P a g e
Vertical Scaling vs. Horizontal Scaling
Aspect Vertical Scaling (Scale-Up) Horizontal Scaling (Scale-Out)

Increasing the capacity of a single server

Adding more servers or machines to the system
Definition (CPU, RAM, storage)

Higher, as larger and more powerful Lower per server, but cost increases with more
Cost hardware is expensive servers

Easier to implement, as it involves More complex, as it requires managing multiple

Complexity upgrading a single machine machines

Limited by the hardware capabilities of a

Can be scaled infinitely by adding more servers
Limitations single server

Performance Performance improves by adding Performance improves through distribution of

Impact resources to a single server load across servers

May require downtime for upgrades or Can be scaled without downtime (if properly
Downtime maintenance configured)

Suitable for small applications with less Suitable for large-scale systems and high-traffic
Use Case traffic applications

Less elastic, harder to quickly Highly elastic, capacity can be adjusted easily by
Elasticity add/remove capacity adding/removing servers

Factors Affecting Scalability

Below are the factors that affects the scalability with their explanation:
 Performance Bottlenecks:
o Performance bottlenecks are points in a system where the performance is significantly lower than
expected.
o These bottlenecks can be caused by various factors such as slow database queries, inefficient
algorithms, or resource contention.
 Resource Utilization:
o Efficiently using resources such as CPU, memory, and disk space is essential for scalability.

62 | P a g e
 o Inefficient resource utilization can lead to bottlenecks and limit the system’s ability to scale.
 Network Latency:
o Network latency refers to the delay in transmission of data over a network.
o High network latency can impact the scalability of distributed systems by causing delays in
communication between nodes.
 Data Storage and Access:
o The way data is stored and accessed can impact scalability.
o Using scalable data storage solutions such as distributed databases or caching mechanisms can
improve scalability.
 Concurrency and Parallelism:
o Designing for concurrency and parallelism can improve scalability by allowing the system to
handle multiple tasks or requests simultaneously, thus improving throughput and reducing
response times.
 System Architecture:
o The overall architecture of the system, including how components are structured and connected,
can impact scalability.
o Using a modular, loosely coupled architecture that can be scaled horizontally (adding more
instances) or vertically (upgrading existing instances) can improve scalability.
Components that help to increase Scalabilty
Below are some of the main components that help to increase the scalability:
 Load Balancer: A load balancer distributes incoming network traffic across multiple servers or resources
to ensure no single resource is overwhelmed. This helps improve performance and availability by
distributing the workload evenly.
 Caching: Caching involves storing frequently accessed data in a cache to reduce the need to access the
original source of the data. This can significantly improve performance by reducing latency and the load
on backend systems.
 Database Replication: Database replication involves copying data from one database to another in real-
time. This helps improve performance and availability by ensuring that multiple copies of the data are
available across different locations or servers.
 Database Sharding: Database sharding involves partitioning a database into smaller, more manageable
parts called shards. Each shard contains a subset of the data, which helps improve scalability by
distributin:g the data across multiple database instances.
 Microservices Architecture: Microservices architecture involves breaking down a monolithic application
into smaller, more independent services. This helps improve scalability by allowing each service to be
scaled independently based on its workload.
 Data Partitioning: Data partitioning involves dividing data into smaller, more manageable parts based on
certain criteria (such as geographic location or user ID). This can improve scalability by distributing the
data across multiple storage devices or database instances.
 Content Delivery Networks (CDNs): CDNs can improve scalability by caching and delivering content from
servers that are geographically closer to users, reducing latency and improving performance.
 Queueing Systems: Queueing systems can improve scalability by decoupling components and allowing
requests to be processed asynchronously. This can help manage spikes in traffic and prevent overload on
backend systems.
Real-World Examples of Scalable Systems
There are many real-world examples of scalable systems that demonstrate the importance and impact of
scalability in modern technology.
 Google: Google’s infrastructure is highly scalable, allowing it to handle billions of search queries and serve
millions of users worldwide. Google uses a distributed system architecture and technologies like Bigtable,
MapReduce, and Spanner to achieve scalability.
 Amazon Web Services (AWS): AWS provides a wide range of scalable cloud computing services, including
computing power, storage, and databases. AWS’s scalable infrastructure allows businesses to quickly
scale resources up or down based on demand.
 Netflix: Netflix’s streaming service is built on a highly scalable architecture that allows it to deliver high-
quality video content to millions of users simultaneously. Netflix uses a combination of caching,
microservices, and cloud computing to achieve scalability.

63 | P a g e
These examples demonstrate the importance of scalability in enabling companies to provide reliable and high-
performance services to a large number of users. Scalability allows these companies to grow their user base,
handle spikes in traffic, and innovate rapidly without being limited by the constraints of their infrastructure
Challenges and Trade-offs in Scalability
Challenges and trade-offs in scalability are important considerations when designing and implementing scalable
systems. Some of the key challenges and trade-offs include:
 Cost vs. Scalability: Scaling a system often involves adding more resources, which can increase costs.
There is a trade-off between the cost of scaling and the benefits gained from improved performance and
availability.
 Complexity: As systems scale, they tend to become more complex. This complexity can make it harder to
maintain and troubleshoot the system, leading to increased operational overhead.
 Latency vs. Throughput: There is often a trade-off between latency (the time it takes for a request to be
processed) and throughput (the number of requests that can be processed per unit of time). Optimizing
for low latency may reduce throughput, and vice versa.
 Data Partitioning Trade-offs: Partitioning data can improve scalability by distributing it across multiple
nodes. However, choosing the right partitioning strategy involves trade-offs, such as balancing the size of
partitions, minimizing data movement, and ensuring data locality.
Conclusion
Scalability is a key factor in system design that allows applications and services to grow smoothly as demand
increases. By building scalable systems, businesses can ensure that their platforms handle more traffic, data, and
users without compromising performance or reliability. Achieving scalability involves using strategies like vertical
scaling, horizontal scaling, and distributed architectures, which help distribute workloads efficiently and improve
overall system resilience.

Which Scalability approach is right for our

Application? | System Design

Which Scalability approach is right for our Application? | System Design

In today’s digital world, the success of an application often depends on its ability to grow smoothly as more users
come on board. This is where scalability comes into play. Scalability means making sure your app can handle more
users and data without slowing down or crashing. But how do you choose the best way to make your app
scalable? In this article, we’ll break it down into simple terms.

Important Topics for the Right Scalability Approach for Your Application
 Scalability
 Different Ways to Make Your Application Scalable
 What Influences Your Choice for choosing the correct method of scalability?
 Making the Right Choice
 How to Test Your App’s Scalability
 Conclusion
Scalability
Scalability, in simple terms, means your app’s ability to handle more and more users or data without breaking a
sweat. Think of it as making sure your car runs just as smoothly with one passenger as it does with a full load.

Different Ways to Make Your Application Scalable

1. Make It Bigger (Vertical Scaling):

This is like giving your car a bigger engine. You’re adding more power to the same vehicle. In tech terms, you
boost your server’s capacity with more CPU, memory, or storage. It’s good for smaller apps, but it has limits
because you can’t infinitely upgrade hardware.
2. Get More Cars (Horizontal Scaling):
Imagine you have a fleet of cars, and they all share the load. This is what horizontal scaling does. You add more
servers or instances to your app, spreading the workaround. It’s great for big apps with lots of users, and it keeps
things running smoothly.
3. Divide and Conquer (Microservices):

64 | P a g e
Think of your app as a puzzle, and each piece of the puzzle is a separate service. Microservices break your app
into these pieces, and you can scale up only the parts that need it. It’s like upgrading one section of a highway
that’s congested, instead of the entire road.
4. No Servers, No Problems (Serverless):
Imagine you don’t have to worry about maintaining your car at all; it just works when you need it. That’s what
serverless does for your app. It automatically handles the scaling for you. It’s cost-efficient and great for
unpredictable workloads.
What Influences Your Choice for choosing the correct method of scalability?
Now, let’s talk about what makes you choose one way over the other:
1. How Your App Is Built (Architecture)
If your app is like a big building with everything inside, vertical scaling might work at first. But if it’s more like a city
with many different parts, horizontal scaling makes more sense.
2. Picking the Right Database
Databases are like your app’s memory. Some databases are good at handling lots of data and users at once
(NoSQL), while others are better for smaller apps (SQL).
3. Counting Your Coins
Money matters! Vertical scaling can be costly because you’re upgrading hardware. Horizontal scaling is usually
cheaper in the long run.
4. Staying Safe
If your app needs a lot of security, vertical scaling might be safer because you have more control over a single
server. It’s like having one locked door instead of many.
5. Time is the Essence
If your app needs to be super fast (like video calls or games), you want horizontal scaling. It puts your app closer
to your users, reducing delay.
6. Up and Down Traffic
If your app’s traffic goes up and down a lot (like a shopping app during holidays), serverless can save you money
by only using resources when needed.
7. Technology Stack
he choice of technology stack can impact scalability options. Some technologies are more suited to horizontal
scaling, such as container orchestration platforms like Kubernetes, while others may be more aligned with vertical
scaling, like traditional monolithic applications.
Making the Right Choice
So, when do you use which method? Here are some scenarios:
Small and Steady
If your application isn’t expected to experience rapid growth in terms of user traffic and resource demands then
choose Vertical Scaling because:
 Vertical scaling involves increasing the capacity of a single server, such as adding more CPU, RAM, or
storage to handle increased loads.
 It is often simpler and requires fewer changes to your application architecture compared to horizontal
scaling.
 Suitable for small-scale applications that don’t need to handle a large number of concurrent users.
Going Big
If you expect a high increase in user traffic and need to ensure your application can handle it, go for Horizontal
Scaling, especially if your app is divided into pieces (microservices) because:
 Horizontal scaling involves adding more servers or instances to your infrastructure, distributing the load
across multiple machines.
 It offers better scalability as you can continue to add more servers as your user base grows.
 Particularly effective for applications that are designed as microservices, allowing you to scale each
service independently.
Variable Loads
For applications with unpredictable traffic patterns or infrequent bursts of activity, serverless can be a good
option because:
 Serverless computing automatically manages the scaling of resources based on demand, making it ideal
for variable workloads.
 You only pay for the actual resources used, which can be cost-effective when your application has idle
periods.

65 | P a g e
  Serverless platforms, such as AWS Lambda or Azure Functions, handle the underlying infrastructure,
reducing operational overhead.
Need for Speed
When your application needs to provide low-latency responses and high performance, horizontal scaling is the
good option because:
 Horizontal scaling allows you to distribute traffic across multiple servers, reducing the load on each server
and improving response times.
 Load balancing techniques can further optimize the distribution of requests for improved speed.
 Useful for applications where responsiveness and speed are critical, such as real-time systems or gaming
applications.
Money Matters
When you have budget constraints but still need to ensure reliability and performance, horizontal scaling is
usually the more cost-effective choice because:
 Horizontal scaling can be cost-effective because you can start with a small number of servers and
gradually add more as your application grows.
 It allows you to optimize resource allocation and reduce costs by scaling up or down based on actual
demand.
 Cloud providers often offer pricing models that align well with horizontal scaling, making it a financially
sound choice.

How to Test Your App’s Scalability?

Testing is like taking your car for a spin to make sure it runs smoothly. Here’s how to do it:
 Load Testing: Use special tools to pretend lots of people are using your app at once. Watch how your app
handles it – you want it to stay fast and error-free.
 Stress Testing: Push your app to its limits. How many users can it handle before things start breaking?
Find out where it breaks and why.
 Adding More Cars: If you’re using horizontal scaling, make sure your load balancer can distribute work
evenly between your servers.
 Checking the Engine (Database): Test how your database handles lots of data. Make sure it can read and
write quickly without errors.
 Fail on Purpose: Simulate things going wrong, like a server crashing. See if your app can handle it and
recover gracefully.
 Keep an Eye Out: After your app is live, use monitoring tools to watch its performance in real-time. Fix
any issues that pop up.
Conclusion:
Making your app scalable is a smart move in today’s tech world. But it’s not a one-size-fits-all decision. You have
to think about how your app is built, how much money you have, and what your users need. Test it out to make
sure it works under pressure. Remember, scalability isn’t a one-time thing – it’s an ongoing process to keep your
app running smoothly as it grows.

Primary Bottlenecks that Hurt the Scalability of an

Application | System Design
Primary Bottlenecks that Hurt the Scalability of an Application | System Design
In the realm of software development and system design, scalability is a paramount concern. Scalability refers to
a system’s ability to handle an increasing amount of workload or growing user base without compromising
performance or response time. Achieving scalability is crucial for ensuring a smooth user experience and
accommodating future growth. However, there are several primary bottleneck conditions that can significantly
hinder the scalability of an application.
Primary Bottlenecks that Hurt the Scalability of an Application
 What are Bottleneck Conditions?
o 1. Database Bottlenecks in System Design
o 2. Network Bottlenecks in System Design
o 3. Server Bottlenecks in System Design
o 4. Authentication Bottlenecks in System Design
o 5. Third-party Services Bottlenecks in System Design
66 | P a g e
 o 6. Code Execution Bottlenecks in System Design
o 7. Data Storage Bottlenecks in System Design
 Conclusion
What are Bottleneck Conditions?
A bottleneck in a system is a point where the flow of data or processing is limited, causing the overall system
performance to degrade. Bottlenecks are like narrow choke points in a highway; when traffic (data or requests)
surpasses the capacity of these points, it leads to congestion and delays. Identifying and addressing bottlenecks is
a fundamental aspect of system design, particularly when striving for scalability.
1. Database Bottlenecks in System Design
 Databases play a central role in many applications, and they are often a primary source of scalability
challenges. Database bottlenecks are performance limitations within a database system that hinder its
ability to efficiently handle requests and transactions. These bottlenecks can significantly impact the
overall performance, scalability, and responsiveness of an application or system.
 Identifying and addressing database bottlenecks is a crucial aspect of system design. Database
bottlenecks occur when the database becomes a performance bottleneck due to issues such as slow
queries, inefficient indexing, inadequate hardware resources, or inadequate indexing.
For example:
If an e-commerce website experiences a surge in traffic during a holiday sale, slow database queries can lead to
delayed order processing, frustrating users, and potentially resulting in abandoned carts.
2. Network Bottlenecks in System Design
 In a distributed system, network bottlenecks can severely hinder scalability. Network bottlenecks refer to
situations where the capacity or performance of a computer network is constrained or limited by a
specific component or resource, causing a slowdown or degradation in the overall system’s performance.
 They can occur at various points in a network topology and can severely impact the efficiency and
responsiveness of an application or system. Understanding and mitigating network bottlenecks is crucial
for designing robust and high-performance systems. These bottlenecks occur when network bandwidth or
latency becomes a limiting factor.
For example:
A video streaming service may encounter network bottlenecks if it doesn’t have adequate content delivery
infrastructure. Users may experience buffering or low-quality video streams when too many requests strain the
network.
3. Server Bottlenecks in System Design
 Server bottlenecks occur when the application server cannot handle an increasing number of requests or
concurrent connections. This can be due to limitations in server resources, such as CPU, memory, or disk
I/O. Imagine a social media platform where a sudden viral post leads to a massive influx of users trying to
access it simultaneously.
 If the server lacks the necessary resources to handle this surge, it may become unresponsive, degrading
the user experience.
For example:
You have a web application that allows users to upload and process images. As the user base grows, the server
begins to experience performance issues. The server’s CPU becomes a bottleneck because the image processing
algorithm used by the application is computationally intensive, causing delays in image processing and overall
sluggishness of the application.
4. Authentication Bottlenecks in System Design
 Authentication is a critical component of many applications, ensuring secure access to user accounts.
Authentication bottlenecks in system design refer to situations where the process of verifying user
identities and granting access to resources becomes a limiting factor in the overall performance and
usability of a system.
 These bottlenecks can result from various factors, including inefficient authentication mechanisms,
excessive user authentication requests, or inadequate authentication infrastructure.
For example:
An e-banking application may experience authentication bottlenecks during peak usage times, causing login
delays if the authentication system cannot keep up with the volume of incoming requests.
5. Third-party Services Bottlenecks in System Design
 Modern applications often rely on third-party services for various functionalities like payment processing,
geolocation, or cloud storage which becomes a limiting factor in the overall performance, reliability, and

67 | P a g e
 scalability of a system. These bottlenecks can occur due to various factors, including the third-party
service’s response time, availability, rate limits, or changes in their API.
 Identifying and addressing third-party services bottlenecks is crucial for designing systems that can
provide consistent and responsive user experiences
For example:
If a ride-sharing app depends on an external mapping service and that service experiences downtime or slow
response times, it can affect the app’s performance and scalability.
6. Code Execution Bottlenecks in System Design
 Code execution bottlenecks in system design refer to situations where the performance and efficiency of
a computer system are hindered by the way software code is designed, written, or executed. These
bottlenecks can occur in many ways, such as slow response times, high CPU utilization, or inefficient use
of system resources.
 Identifying and addressing code execution bottlenecks is crucial for designing systems that deliver optimal
performance and scalability.
For example:
Inefficient algorithms for rendering complex data in a web application’s front-end code can lead to slow page
loads and lower user satisfaction. Detecting and optimizing these code bottlenecks is crucial for achieving
scalability.
7. Data Storage Bottlenecks in System Design
 Data storage bottlenecks in system design occur when the storage infrastructure and mechanisms in a
system become a limiting factor in terms of performance, capacity, or reliability. These bottlenecks can
impact the overall functionality and efficiency of the system.
 This might include slow access to file storage systems or inefficient utilization of disk space, leading to
issues such as slow data access, data loss, or scalability problems. Identifying and addressing data storage
bottlenecks is critical for designing systems that can handle data effectively.
For example:
Consider a cloud-based file-sharing platform; if the underlying file storage system struggles to handle an
increasing number of files or doesn’t provide efficient data retrieval, it can impede the platform’s ability to scale
gracefully.
Conclusion:
Scalability is a pivotal consideration in system design, ensuring that applications can grow and adapt to changing
demands. However, primary bottleneck conditions can hinder scalability and compromise the user experience.
Recognizing and addressing these bottlenecks is essential for building robust and scalable systems. Whether it’s
optimizing database queries, improving network infrastructure, upgrading server resources, enhancing
authentication mechanisms, fine-tuning code execution, or optimizing data storage, proactive measures can
alleviate these bottlenecks and pave the way for a more scalable and reliable application.

UNIT-3
Databases in Designing Systems
Databases in Designing Systems
 Which Database to Choose while designing a system – SQL or NoSQL
 File and Database Storage Systems in System Design
 Database Replication in System Design
 Block, Object, and File Storage
 Normalization Process in DBMS
 Denormalization in Databases

SQL vs NoSQL: Which Database to Choose in System Design?

When designing a system, one of the most critical system design choices you will face is choosing the proper
database management system (DBMS). The choice among SQL vs. NoSQL databases can drastically impact your

68 | P a g e
system’s overall performance, scalability, and usual success. This is why we have brought this detailed comparison
of SQL vs NoSQL databases in System Design, to help you determine which database to choose while designing a
scalable system. We’ll also speak about eventualities in which SQL or NoSQL databases are extra suitable, types of
NoSQL databases, and various SQL server configurations.

Table of Content
 What is SQL (Structured Query Language) Database?
 What is NoSQL (Not Only SQL) Database?
 SQL vs. NoSQL: A Comparative Analysis
 SQL vs NoSQL in System Design – Data Model and Schema
 SQL vs NoSQL in System Design – Scalability and Performance
 SQL vs NoSQL in System Design – Query Language and Transactions
 SQL vs NoSQL in System Design – Flexibility and Schema Evolution
 SQL vs NoSQL in System Design – Use Cases and Applications
 SQL vs NoSQL in System Design – Data Integrity and Relationships
 SQL vs NoSQL in System Design – Security and Authentication
 SQL vs NoSQL in System Design – Community Support and Ecosystem
 SQL vs NoSQL in System Design – Cost Considerations
 SQL vs NoSQL in System Design – Decision Factors
 SQL vs NoSQL in System Design – Case Studies and Real-world Examples
 SQL database over NoSQL database in System Design
 NoSQL database over SQL database in System Design
SQL and NoSQL are awesome categories of database control systems, each with its very own set of traits and use
cases. Let’s have a look at these two:
What is SQL (Structured Query Language) Database?
SQL databases, frequently known as relational databases, are primarily based on a nicely hooked-up and
dependent information model. Here are some key features of SQL databases:
 Tabular Data Model: SQL databases organize records into tables with rows and columns. Each table
contains some set of attributes also known as entity. Each row of the table is known as a record. Columns
define the attributes or residences of the information.
 Fixed Schema: SQL databases require a predefined schema, which means that you must define the
structure of the records, specifying record types and relationships earlier than adding records to the
database. This makes SQL databases suitable for based and steady information.
 ACID Compliance: SQL databases are commonly ACID-compliant, which means they make certain records
consistency and integrity via Atomicity, Consistency, Isolation, and Durability.
 Structured Query Language (SQL): SQL databases use a standardized query language to control and
retrieve facts. SQL is strong and supports complex queries, making it suitable for applications requiring
statistical analytics and reporting.
 Strong Relationships: SQL databases excel in coping with complex relationships between facts tables.
 Vertical Scalability: SQL databases commonly scale vertically by adding extra sources to an unmarried
server. While this will be effective to a positive extent, it has boundaries and can turn out to be steeply
priced for large-scale programs.
Common examples of SQL databases are:
 MySQL: An open-source relational database this is widely utilized in diverse packages.
 PostgreSQL: A powerful open-source relational database known for its extensibility and assist for
advanced functions.
 Oracle: A commercial relational database regarded for its robustness and scalability.
 Microsoft SQL Server: A popular commercial database system advanced by means of Microsoft, widely
used in Windows-based packages.
What is NoSQL (Not Only SQL) Database?
NoSQL databases are designed to handle unstructured or semi-based facts and provide flexibility, scalability, and
performance. Here are some key capabilities of NoSQL databases:
 Flexible Data Model: NoSQL databases use quite a few statistics models, along with key-cost pairs,
document stores, huge-column shops, and graph databases.
 Schema-less: NoSQL databases are schema-less, this means that statistics can be inserted with out a
predefined schema.

69 | P a g e
  BASE (Basically Available, Soft State, Eventually Consistent): Instead of ACID compliance, NoSQL
databases frequently comply with the BASE version. BASE prioritizes excessive availability and
performance over strict consistency. This makes NoSQL databases suitable for allotted and actual-time
structures, in which keeping on the spot consistency across nodes can be difficult.
 Proprietary Query Language: NoSQL databases typically have their very own query languages tailored to
their particular statistics models. These question languages are often more sincere and better acceptable
to the facts structure.
 Horizontal Scalability: NoSQL databases excel in horizontal scalability. They can distribute statistics
throughout a couple of nodes or clusters, bearing in mind seamless growth to handle increasing statistics
and traffic masses. Less Emphasis on Relationships: While NoSQL databases can help relationships, they
usually do not put into effect them as rigorously as SQL databases.
Common examples of NoSQL databases consist of:
 MongoDB: A popular document shop that is flexible and scalable.
 Cassandra: A wide-column shop recognised for its ability to address huge amounts of information and
excessive write throughput.
 Redis: A key-fee save that excels in information caching and actual-time analytics. Neo4j: A graph
database designed for programs with complicated relationships, inclusive of social networks and advice
engines.

SQL vs. NoSQL: A Comparative Analysis

To assist you make an informed choice, allow’s compare SQL and NoSQL databases across various dimensions:
Aspect SQL Database in System Design NoSQL Database in System Design

Flexible (Key-Value, Document,

Tabular (Structured)
Data Model Graph, and so forth.)

Schema Strict, predefined schema Flexible, schema-less

Query Language SQL Proprietary or language-specific

Usually BASE (Basically Available,

ACID-compliant
Transaction Support Soft state, Eventually consistent)

Scaling Vertical scaling Horizontal scaling

Eventual consistency (can be

Strong
Data Consistency adjusted)

Suitable for applications requiring

High availability and scalability,
Complex queries, transactions
real-time packages, fast read and
Use Cases write operations

Examples MySQL, PostgreSQL, Oracle MongoDB, Cassandra, Redis

SQL vs NoSQL in System Design – Data Model and Schema

 Structured Data in SQL:
o SQL databases enforce a rigid schema where data types and relationships are predefined.
Changes to the schema can be complex and may require downtime.
 Flexible Schema in NoSQL:
o NoSQL databases embrace a dynamic schema, allowing for the insertion of data without a
predefined structure. This flexibility accommodates evolving data requirements.
 Impact on System Design:
70 | P a g e
 o The choice between a structured or flexible schema depends on the nature of the data and the
project’s adaptability to changing requirements.
SQL vs NoSQL in System Design – Scalability and Performance
 Vertical Scaling in SQL
o SQL databases traditionally scale vertically by adding more resources to a single server, but this
has limitations.
 Horizontal Scaling in NoSQL
o NoSQL databases shine in horizontal scaling, distributing data across multiple servers to handle
increasing loads seamlessly.
 Considerations for High Traffic Systems
o The scalability requirements of your system and the anticipated traffic should guide your decision
on vertical or horizontal scaling.
SQL vs NoSQL in System Design – Query Language and Transactions
 SQL’s Standardized Query Language
o SQL databases use a standardized language for querying data, making it easier for developers
familiar with SQL syntax.
 NoSQL Querying Approaches
o NoSQL databases vary in their query languages, with some using traditional SQL and others
adopting unique approaches.
 ACID Transactions vs BASE Consistency
o The choice between strong ACID transactions (SQL) and eventual consistency (NoSQL) depends on
the importance of data integrity in your application.
SQL vs NoSQL in System Design – Flexibility and Schema Evolution
 Schema Evolution Challenges in SQL
o Adapting a SQL database to evolving data requirements may involve complex schema changes
and potential downtime.
 Dynamic Schema Evolution in NoSQL
o NoSQL databases accommodate dynamic schema evolution, allowing developers to adapt to
changing needs without significant disruption.
 Adapting to Changing Requirements
o Consider the likelihood of changing data structures and whether your system can gracefully
handle such changes.
SQL vs NoSQL in System Design – Use Cases and Applications
 Common Use Cases for SQL Databases
o SQL databases excel in scenarios requiring complex transactions, strict data integrity, and well-
defined relationships.
 Scenarios Where NoSQL Excels
o NoSQL databases shine in applications demanding high scalability, handling large volumes of
unstructured data, and rapid development cycles.
 Hybrid Approaches in Real-world Systems
o Hybrid approaches, combining SQL and NoSQL databases, are increasingly common, leveraging
the strengths of each for different aspects of a system.
SQL vs NoSQL in System Design – Data Integrity and Relationships
 Maintaining Data Integrity in SQL
o ACID transactions in SQL databases ensure data consistency and integrity, vital for applications
with critical transactional requirements.
 Handling Relationships in NoSQL
o NoSQL databases often require denormalization to handle relationships efficiently, and the level
of consistency may vary.
 Choosing Based on Relationship Complexity
o Evaluate the complexity of relationships within your data to determine the most suitable
database model.
SQL vs NoSQL in System Design – Security and Authentication
 SQL Security Mechanisms
o SQL databases come with well-established security mechanisms, including user roles, access
controls, and encryption.
 NoSQL Database Security Considerations

71 | P a g e
 o NoSQL databases may have varying levels of security features, and implementing access controls
is crucial for protecting sensitive data.
 Best Practices for Ensuring Data Security
o Follow best practices for securing databases, regardless of the chosen type, to safeguard against
potential threats.
SQL vs NoSQL in System Design – Community Support and Ecosystem
 Established SQL Ecosystem
o SQL databases benefit from a mature ecosystem, extensive community support, and a wealth of
tools and frameworks.
 Growing NoSQL Community
o The NoSQL community is dynamic, with a growing ecosystem and an array of databases catering
to diverse needs.
 Impact on Developer Experience
o Consider the impact on your development team’s experience and expertise when choosing
between SQL and NoSQL.
SQL vs NoSQL in System Design – Cost Considerations
 Licensing and Infrastructure Costs in SQL
o SQL databases may involve licensing fees, and scaling vertically can incur higher infrastructure
costs.
 Scalability and Cost Efficiency in NoSQL
o NoSQL databases, with their horizontal scaling capabilities, often offer cost-effective solutions for
handling increased workloads.
 Evaluating Total Cost of Ownership (TCO)
o Factor in licensing, infrastructure, maintenance, and scaling costs when assessing the overall TCO
for your database.
SQL vs NoSQL in System Design – Decision Factors
 Project Requirements
o Align your choice with the specific requirements of your project, considering data structures,
scalability needs, and development pace.
 Team Expertise
o Evaluate your development team’s expertise in SQL or NoSQL, as this can significantly impact the
efficiency of system development and maintenance.
 Future Scalability and Adaptability
o Consider the long-term scalability and adaptability of your chosen database, ensuring it aligns
with your project’s growth trajectory.
SQL vs NoSQL in System Design – Case Studies and Real-world Examples
 Successful Implementations of SQL Databases
o Explore real-world examples where SQL databases have played a crucial role in achieving success
and meeting specific project requirements.
 NoSQL Database Success Stories
o Learn from successful implementations of NoSQL databases, showcasing their versatility and
effectiveness in diverse applications.
 Lessons Learned from Notable Cases
o Draw valuable lessons from both SQL and NoSQL implementations, understanding how certain
decisions contributed to project success or challenges.
When should you choose SQL database over NoSQL database in System Design?
Challenges of using NoSQL Databases in System Design:
 Less Support for Complex Queries: NoSQL databases aren’t well-suitable for complicated joins and
superior queries.
 Inconsistent Data: NoSQL databases might also prioritize performance over strict consistency, probably
leading to facts inconsistencies in dispensed systems.
 Limited Transaction Support: Some NoSQL databases sacrifice transaction aid for speed and scalability.
Benefits of using SQL database in System Design
SQL databases are appropriate for unique situations, consisting of:
 Complex Queries: If your application requires advanced queries and complex reporting, SQL databases
excel on this location because of their structured schema and SQL question language.

72 | P a g e
  Data Integrity: When facts consistency and integrity are paramount, particularly in financial or regulatory
applications, SQL databases with ACID compliance are the desired preference.
 Transactions: SQL databases are the go-to option for packages that require support for multi-step, ACID-
compliant transactions, like e-commerce systems.
When should you choose NoSQL database over SQL database in System Design?
Challenges of using SQL Databases in System Design:
 Fixed Schema: SQL databases require a predefined schema, making it hard to evolve to converting data
systems.
 Lack of Scalability: Scaling SQL databases horizontally can be complicated and high-priced.
 Slower for Read-Heavy Workloads: SQL databases can be less efficient for read-heavy workloads,
specially when managing big datasets.
Benefits of using NoSQL database in System Design
NoSQL databases shine in certain situations:
 High Scalability: If your machine wishes to handle a large amount of records and visitors, NoSQL
databases provide horizontal scalability, making them a top desire for net and mobile programs.
 Flexible Schema: When your information structure is dynamic and may evolve through the years, NoSQL
databases with schema-less designs permit for simpler version.
 Real-time Analytics: For real-time analytics and processing of streaming facts, NoSQL databases are
frequently the favored option due to their pace and versatility.
SQL vs NoSQL: Which Database to Choose in System Design?
Aspect SQL NoSQL

Enforces a structured schema with Embraces a flexible schema,

predefined tables and allowing for dynamic and evolving
Data Model and Schema relationships. data structures.

Excels in horizontal scaling,

Traditionally scales vertically by
distributing data across multiple
adding more resources to a single
servers to handle increasing loads
server.
Scalability and Performance seamlessly.

Varied query languages, with some

Standardized SQL language for using SQL and others adopting
querying data. unique approaches. Transaction
Query Language and Transactions handling follows ACID principles.

Dynamic schema evolution allows

Rigid schema may require complex for adaptation to changing data
changes with potential downtime. requirements without significant
Flexibility and Schema Evolution disruption.

Ideal for applications demanding

Suitable for complex transactions, high scalability, handling large
strict data integrity, and well- volumes of unstructured data, and
defined relationships. rapid development cycles. Hybrid
Use Cases and Applications approaches are common.

Maintains data integrity through Requires denormalization for

ACID transactions. Relationships efficient relationship handling, and
Data Integrity and Relationships are well-defined. the level of consistency may vary.

Security and Authentication Well-established security Varies in security features, with the

73 | P a g e
Aspect SQL NoSQL

mechanisms, including user roles, need for implementing access

access controls, and encryption. controls to protect sensitive data.

Mature ecosystem with extensive Dynamic and growing community

community support, tools, and with a variety of databases
Community Support and Ecosystem frameworks. catering to diverse needs.

Often offers cost-effective

solutions with horizontal scaling
May involve licensing fees, and
capabilities for handling increased
scaling vertically can incur higher
workloads. Considerations include
infrastructure costs.
licensing, infrastructure,
Cost Considerations maintenance, and scaling costs.

Align choice with specific project Evaluate team expertise in SQL or

requirements, considering data NoSQL, and consider long-term
structures, scalability needs, and scalability and adaptability aligned
Decision Factors for System Design development pace. with project growth.

Versatile implementations
Successful implementations in
showcasing effectiveness in diverse
various scenarios, contributing to
Case Studies and Real-world applications. Lessons learned from
project success.
Examples notable cases.

Conclusion
In system design, the choice between SQL and NoSQL databases is a pivotal decision with far-reaching
implications. By understanding the pros and cons of each database type and carefully evaluating your system’s
requirements, scalability needs, and team expertise, you can navigate this decision-making process effectively.
Choose wisely, and may your database selection in your System Design contribute to the success of your systems.

File and Database Storage Systems in System

Design
File and Database Storage Systems in System Design

In system design, File and Database Storage Systems play a pivotal role in managing and organizing data
efficiently. These systems provide the foundation for storing, retrieving, and organizing information in
applications, ensuring data integrity and accessibility. File systems handle structured and unstructured data, while
database systems offer structured data management with advanced querying capabilities. Effective integration of
these storage systems is essential for designing scalable and reliable software applications, making them integral
components of modern system architecture.

Important Topics for File and Database Storage Systems in System Design
 File-based storage system
 Database file-based storage system
 Hadoop Distributed File System
 RDBMS
 Difference between RDBMS and File-Based System
 Advantages of RDBMS over File-Based System
 Advantages of File Based over RDBMS System
File-based storage system
74 | P a g e
File-storage/file-level/file-based storage is an effective hierarchical approach used to store data in an organized
way on a computer hard drive or on a Network Attached Storage (NAS) device. Initially, the data (to be stored) is
stored in files. Next, the files are organized in folders under a hierarchy of directories and subdirectories. To
locate a saved file on a computer system, all one requires is a path i.e. from directory to subdirectory and to
folder to file.
Examples: cloud-based file storage systems, network drives, computer hard drives, and flash drives.
Pros of File-based storage system Cons of File-based storage system

Files can be easily accessed by a user on a small scale Maintaining and retrieving a large number of files can
and can be easily managed. be challenging.

It is hard to work with unstructured data and becomes

Most users are familiar with it.
expensive at large levels.

Database file-based storage system

A Database file-based storage system is a type of database management system (DBMS) storing data in files on a
computer’s file system. They include a data file system for database data files and a Reco file system for storing
archive files and backups. Although file-based databases are simpler and easier to manage than relational
databases at the same time they are also less powerful and scalable.
Examples: Microsoft Access, SQLite, FlatfileDB etc.
Pros of Database file-based storage system Cons of Database file-based storage system

It is simple to set up and manage and relatively It is not as powerful or flexible as relational databases and has
inexpensive. limited scalability.

Performance rate for small datasets is good. Managing large datasets might be difficult for the users.

It is portable. The system is vulnerable to data corruption and loss.

Hadoop Distributed File System

The Hadoop Distributed File System (HDFS) is the primary data storage system used by Hadoop applications.
Besides storing such huge data, the files are stored across multiple machines in redundant fashion to rescue the
system from possible data losses in case of failure. Unlike other distributed systems, HDFS is highly fault-tolerant
and designed using low-cost hardware.
Key components of HDFS are as follows:
 NameNode
 DataNode
 Secondary Name Node
 Standby Name Node
RDBMS
RDBMS stands for Relational Database Management System, based on the relational model introduced by E.F.
Codd. It stores data in the form of tables ( having rows, columns and tuples) with the help of Structured Query
Language (SQL) to access the database. All modern database management systems like SQL, MS SQL Server, IBM
DB2, ORACLE, My-SQL, and Microsoft Access are based on RDBMS.
Difference between RDBMS and File-Based System
Point of
Difference RDBMS File-Based System

RDBMS makes use of a table in which the In file-based system files are organized in
1. Data headers serve as column names and the rows folders under a hierarchy of directories and
Structure carry the relevant data. subdirectories

75 | P a g e
Point of
Difference RDBMS File-Based System

2. Data SQL is the standard language used to In a file based system data is manipulated
Manipulation manipulate data in RDBMS. by File APIs.

3. Scalability Scalability is high. Scalability is low.

Performance rate is good for small datasets

Performance rate is overall good.
4. Performance but poor for larger ones.

It is more complex and powerful requiring It is simpler and easier to manage than
5. Complexity more resoureces to manage. RDBMS.

Advantages of RDBMS over File-Based System

RDBMS (Relational Database Management System) provides a number of advantages over file-based systems
namely :
 Data integrity: Data integrity is enforced by RDBMS. The data is stored in a consistent and accurate
manner by using constraints such as primary keys, foreign keys, and data types.
 Data security: A variety of security features are provided here to protect the data from unauthorized
access, modification, or deletion. The mentioned features include authentication, authorization, and
encryption.
 Data concurrency: Besides allowing multiple users to access and modify data simultaneously it does not
cause conflicts. All this is done by using locking mechanisms, ensuring only one user can modify a piece of
data at a time.
 Data scalability: These databases are designed to scale to large amounts of data. Thus can be easily
scaled up or down to meet the needs of any application.
 Data flexibility: RDBMS can be used to store a huge variety of data types making it flexible for it’s users
also idealising it for a wide range of applications.
Advantages of File Based over RDBMS System
File based storage systems have numerous advantages over RDBMS systems. They are as follows ;
 Simplicity: File-based systems follow a hierarchichal structure making them simpler to set up and manage
than RDBMS systems. Thus they do not require any special software or expertise to use.
 Portability: File-based system(s) is more portable than RDBMS system as data here can be easily
transferred between different computers and operating systems.
 Performance: File-based systems can provide overall better performance for small to medium-sized
datasets.
 Cost: A file-based system is less expensive to purchase and maintain than the RDBMS system.

Database Replication in System Design

Database Replication in System Design

Database replication is a crucial concept in system design, especially for ensuring data availability, reliability, and
scalability. It involves creating and maintaining multiple copies of a database across different servers to enhance
performance and fault tolerance. In this article, we will delve into the fundamentals of database replication, its
various types, and its importance in system design.
Important Topics for the Database Replication in System Design
 What is Database Replication?
 Why do we need Database Replication?
 Types of Database Replication
o Master-Slave Replication

76 | P a g e
 o Master-Master Replication
o Snapshot Replication
o Transactional Replication
o Merge Replication
 Strategies for Database Replication
o Full Replication
o Partial Replication
o Selective Replication
o Sharding
o Hybrid Replication
 Configurations of Database Replication in System Design
o Synchronous Replication Configuration
o Asynchronous Replication Configuration
o Semi-synchronous Replication Configuration
 What Factors to consider when choosing a Replication Configuration?
 Benefits of Database Replication
 Challenges of Database Replication
What is Database Replication?
Database replication involves creating and maintaining duplicate copies of a database on different servers. It is
crucial for enhancing data availability, reliability, and scalability in modern systems.
 By replicating data across multiple servers, organizations can ensure that their data remains accessible
even if one server fails.
 This redundancy also improves data reliability, as there are multiple copies available to restore data in
case of corruption or loss.
 Additionally, database replication can help distribute the workload among servers, improving
performance and scalability.
Why do we need Database Replication?
Database replication is important for several reasons:
 High Availability: Replication ensures that data is available even if one or more servers fail. By
maintaining copies of data on multiple servers, applications can continue to operate without interruption.
 Disaster Recovery: Replication provides a means to recover data in the event of a disaster. By having
copies of data stored in different locations, organizations can quickly restore operations after a disaster.
 Load Balancing: Replication allows for distributing read queries across multiple servers, reducing the load
on any single server and improving performance.
 Fault Tolerance: Replication improves fault tolerance by ensuring that if one server fails, another can take
over with minimal disruption.
 Scalability: Replication can improve scalability by allowing for the distribution of write operations across
multiple servers, reducing the load on any single server.
 Data Locality: Replication can be used to bring data closer to users, reducing latency and improving the
user experience.
Types of Database Replication
Database replication is like making copies of your important documents so you have backups in case something
happens to the original. There are different ways to make these copies, like having one main copy (master) that
gets updated and then making copies (slaves) of that updated version. Another way is to have multiple main
copies (masters) that can all be updated and share those updates with each other.
Let’s understand the different types of database replication:
1. Master-Slave Replication
Master-slave replication is a method used to copy and synchronize data from a primary database (the master) to
one or more secondary databases (the slaves).
 In this setup, the master database is responsible for receiving all write operations, such as inserts,
updates, and deletes.
 The changes made to the master database are then replicated to the slave databases, which maintain a
copy of the data.

77 | P a g e
Real-World Example of Master-Slave Replication
Imagine a library with two branches
 Master branch: This is the main library with the original and constantly updated collection of books.
 Slave branch: This is a smaller branch that receives copies of new books from the master branch at
regular intervals. Students can only borrow books that are physically present in the slave branch.
2. Master-Master Replication
Master-master replication, also known as bidirectional replication, is a setup in which two or more databases are
configured as master databases, and each master can accept write operations. This means that changes made to
any master database are replicated to all other master databases in the configuration.
 In master-master replication, communication occurs bidirectionally between the master databases.
 When a write operation is performed on one master database, that change is replicated to all other
master databases.
 If conflicting writes occur on different master databases, conflict resolution mechanisms are needed to
ensure data consistency.

Real-World Example of Master-Master Replication

Imagine two highly trained air traffic controllers managing air traffic in a busy airspace
 Each controller has a designated sector and full authority to direct planes within their zone.
 They constantly communicate and share information to ensure flight paths don’t conflict, maintaining
overall airspace safety.
 If one controller becomes unavailable, the other can seamlessly take over responsibility for both
sectors, guaranteeing uninterrupted traffic flow.
3. Snapshot Replication
Snapshot replication is a method used in database replication to create a copy of the entire database at a specific
point in time and then replicate that snapshot to one or more destination servers. This is typically done for
reporting, backup, or distributed database purposes.

78 | P a g e
Real-World Example of Master-Slave Replication
Imagine taking a photo of a messy room (database) at a specific time
 The snapshot captures the state of the room (database) at that exact moment.
 You can use the snapshot to restore the room (database) to its previous state if needed.
4. Transactional Replication
Transactional replication is a method for keeping multiple copies of a database synchronized in real-time.
 This means that any changes made to a specific table (or set of tables) in one database, called the
publisher, are immediately replicated to other databases, called subscribers.
 This ensures that all copies of the data are identical at any given moment, providing data consistency
across multiple locations.

Real-World Example of Transactional Replication

Picture a live stock market with constantly changing prices
 Every price change (transaction) is immediately broadcasted to all connected screens (replicas).
 Everyone sees the same price updates in real-time.
5. Merge Replication
Merge replication is a database synchronization method allowing both the central server (publisher) and its
connected devices (subscribers) to make changes to the data, resolving conflicts when necessary.
This definition captures the key essence of merge replication in a concise and accurate way, highlighting its two
main characteristics:
 Two-way synchronization: Unlike transactional replication, where updates flow primarily from the
publisher to subscribers, merge replication allows bidirectional data flow. This means both the central
server and devices can modify the data,even when offline.
 Conflict resolution: With multiple parties editing the same data, conflicts are bound to occur. Merge
replication employs pre-defined rules or user interventions to resolve conflicting changes, ensuring data
consistency across all copies.

79 | P a g e
Real-World Example of Master-Slave Replication
Imagine a team working on a shared document (database) in Google Docs
 Team members can edit the document offline (locally) and their changes are saved temporarily.
 When they connect online, their changes are merged with the main document, resolving any conflicts.
Strategies of Database Replication
Database replication strategies define how data is selected, copied, and distributed across databases to achieve
specific goals such as scalability, availability, or efficiency. Here are some common database replication strategies:
1. Full Replication
Full replication, also known as whole database replication, is a strategy where the entire database is replicated to
one or more destination servers. This means that all tables, rows, and columns in the database are copied to the
destination servers, ensuring that the replicas have an exact copy of the original database.
For Example:
An e-commerce website uses full replication to replicate its entire product catalog and customer database to
multiple servers. This ensures that all product information and customer data are available on all servers,
providing high availability and fault tolerance.

2. Partial Replication
Partial replication is a strategy where only a subset of the database is replicated, such as specific tables, rows, or
columns, rather than replicating the entire database. This approach allows for more efficient use of resources and
can be beneficial when only certain data needs to be replicated for reporting, analysis, or other purposes.
For Example:
A financial institution replicates only the most frequently accessed customer account information to a secondary
database for reporting purposes. This reduces the resource requirements of replication by replicating only the
most critical data.

80 | P a g e
3. Selective Replication
Selective replication is a database replication strategy that involves replicating data based on predefined criteria
or conditions. Unlike full replication, which replicates the entire database, or partial replication, which replicates a
subset of the database, selective replication allows for more granular control over which data is replicated. This
can be useful in scenarios where only specific data needs to be replicated to reduce resource requirements and
improve efficiency.
For Example:
A social media platform replicates only the posts and comments that have been liked or shared by a large number
of users to a secondary database. This reduces the amount of data transferred and stored on the replicas by
replicating only the most relevant or important data.

4. Sharding
Sharding is a database scaling technique that involves partitioning data across multiple database instances
(shards) based on a key. This approach allows for distributing the workload and data storage across multiple
servers, improving scalability and performance. Sharding is commonly used in environments where a single
database server is unable to handle the load or storage requirements of the application.
For Example:
An online gaming company shards its user database based on geographic location, with each shard responsible for
users in a specific region. This improves scalability by distributing the workload and data storage across multiple
servers.

5. Hybrid Replication
Hybrid replication is a database replication strategy that combines multiple replication techniques to achieve
specific goals. This approach allows for the customization of replication methods based on the requirements of
different parts of the database or application.
81 | P a g e
For Example:
A healthcare organization uses a hybrid replication approach to replicate patient records. It uses full replication for
critical patient data that requires high availability and partial replication for less critical data that is only accessed
occasionally.
Configurations of Database Replication in System Design
Database replication can be configured and operated in different modes or configurations to achieve specific
goals related to data consistency, availability, and performance.
 Synchronous replication
 Asynchronous replication
 Semi-synchronous replication
1. Synchronous Replication Configuration
Synchronous replication is a database replication method in which data changes are replicated to one or more
replicas in real-time, and the transaction is not considered committed until at least one replica has acknowledged
receiving the changes. This method ensures that the primary database and its replicas are always in sync,
providing a high level of data consistency.
For Example:
Banking application uses synchronous replication to ensure that all transactions are replicated to a secondary
database in real-time for data consistency and disaster recovery purposes.

2. Asynchronous Replication Configuration

Asynchronous replication is a database replication method in which data changes are replicated to one or more
replicas after they are made on the primary database, without waiting for acknowledgment from the replicas.
 This method allows for faster transaction processing on the primary database, but it can result in a slight
delay in data consistency between the primary and replica(s)
 As changes made to the primary database do not always replicate to the replica databases in
asynchronous replication, which is a type of database replication.
For Example:
An e-commerce website uses asynchronous replication to replicate product inventory data from the primary
database to a secondary database for reporting and analysis purposes.

3. Semi-synchronous Replication Configuration

Semi-synchronous replication is a database replication method that combines aspects of synchronous and
asynchronous replication.
 In semi-synchronous replication, data changes are replicated to at least one replica synchronously,
ensuring strong data consistency for critical data, while other replicas are updated asynchronously for
better performance.
 This approach provides a balance between strong data consistency and improved performance.
For Example :
A financial institution uses semi-synchronous replication for its transaction processing system.
 When a customer initiates a funds transfer transaction, the transaction is processed on the primary
database.
 The changes made by the transaction are replicated synchronously to at least one replica to ensure strong
data consistency for critical financial data. Other replicas are updated asynchronously to improve
performance.
82 | P a g e
What Factors to consider when choosing a Replication Configuration?
When choosing a replication configuration for your database system, several key factors should be considered to
ensure that the selected configuration meets your requirements. Here are some important factors to consider:
 Data Consistency Requirements:
o Consider the level of data consistency required for your application.
o Synchronous replication provides strong consistency but may impact performance
o While asynchronous replication offers better performance but may result in eventual consistency.
 Performance Requirements:
o Evaluate the performance impact of the replication configuration on your database system.
o Synchronous replication may introduce latency due to waiting for acknowledgments, while
asynchronous replication can improve performance but may result in data lag.
 Network Bandwidth and Latency:
o Consider the available network bandwidth and latency between the primary database and its
replicas.
o Synchronous replication requires more bandwidth and is sensitive to latency, while asynchronous
replication is more tolerant of network issues.
 Failover and High Availability:
o Determine how quickly your system needs to recover from failures.
o Synchronous replication provides immediate failover capabilities but may have higher latency,
while asynchronous replication may have a delay in failover but can offer better performance.
 Data Loss Tolerance:
o Assess the tolerance for potential data loss in your application.
o Synchronous replication minimizes data loss but may impact performance, while asynchronous
replication may result in data loss in case of a failure.
Benefits of Database Replication
Database replication offers numerous benefits, including high availability, improved performance, disaster
recovery capabilities, scalability, and load balancing.
 High Availability: Database replication provides redundancy, ensuring that if one database server fails,
another can take over, minimizing downtime and ensuring continuous availability of data.
 Improved Performance: By distributing read queries across multiple replicas, database replication can
improve read performance, as each replica can handle a portion of the workload.
 Disaster Recovery: Replicated data can be used for disaster recovery purposes, ensuring that data is
protected and can be restored in the event of a disaster.
 Scalability: Database replication can help scale read operations by distributing them across multiple
replicas, allowing for better performance as the workload increases.
 Load Balancing: Replication can be used for load balancing, distributing write operations across multiple
servers to prevent any single server from becoming a bottleneck.
Challenges of Database Replication
Despite its benefits, database replication also poses several challenges, such as ensuring data consistency,
managing complexity, addressing cost considerations, resolving conflicts, and dealing with latency.
 Data Consistency: Maintaining consistency between replicas can be challenging, especially in
asynchronous replication scenarios where there may be a delay in replicating data.
 Complexity: Database replication adds complexity to the system, requiring careful configuration and
management to ensure that data is replicated correctly and efficiently.

83 | P a g e
  Cost: Setting up and maintaining a replicated database environment can be costly, especially for large-
scale deployments with multiple replicas.
 Conflict Resolution: In multi-master replication scenarios, conflicts may arise when the same data is
modified on different replicas simultaneously, requiring conflict resolution mechanisms.
 Latency: Synchronous replication, which requires acknowledgment from replicas before committing
transactions, can introduce latency and impact the performance of the primary database.

Want to be a Software Architect or grow as a working professional? Knowing both Low and High-Level System
Design is highly necessary. As such, our course fits you perfectly: Mastering System Design: From Low-Level to
High-Level Solutions. Get in-depth into System Design with hands-on projects and Real-World Examples. Learn
how to come up with systems that are scalable, efficient, and robust—ones that impress. Ready to elevate your
tech skills? Enrol now and build the future!

Block, Object, and File Storage in Cloud with

Difference
Block, Object, and File Storage in Cloud with Difference
These are all different kinds of formats that hold, store, organize, and present the data in various formats in
accordance with their determining factors. In general file storage is hierarchical storage of data as seen in
operating systems such as macOS. Block stores in even-spaced chunk volumes and Object storage is used only in
managing data and mapping it with associated metadata.
1. Block storage
Block storage involves dividing data into fixed-sized blocks and storing them on block devices such as hard drives
or solid-state drives (SSDs). These blocks are accessed using low-level block-level protocols, typically through
storage area networks (SANs) or direct-attached storage (DAS).
Key features of block storage include:
 Low-level access: Blocks can be read from or written directly, allowing for efficient and fast random
access.
 Ideal for databases and transactional workloads: Block storage is commonly used for applications that
require low-latency, high-performance storage, such as databases or virtual machines.
Options:
1. Amazon Elastic Block Store (EBS).
2. Azure Virtual Machines (VMs) can be used with the managed discs service for block volumes that Azure
offers.
3. Google Cloud (Zonal persistent disk): Efficient and reliable block storage,
2. Object storage
Files are divided into little parts and dispersed over hardware in a flat structure. Instead of being maintained as
files in directories or as blocks on servers, the data is divided up into discrete parts called objects and kept in a
single repository with object storage. Object storage systems typically use a RESTful API for accessing and
managing data.
Key features of object storage include:
 Scalability and Durability: Object storage is highly scalable and can handle massive amounts of data. It
also provides built-in redundancy and fault tolerance for data durability.
 Flexible Metadata: Each object can have custom metadata associated with it, enabling rich data
management and search capabilities.
 Suitable for Unstructured Data: Object storage is well-suited for storing and retrieving large amounts of
unstructured data, such as media files, backups, or log files.
Options:
1. Amazon Simple Storage Service (Amazon S3)
2. Azure Blob Storage
3. Google Cloud Storage buckets
3. File storage
File storage stores data as files and presents it to its final users as a hierarchical directories structure. It is typically
accessed using file-level protocols like Network File System (NFS) or Server Message Block (SMB). File storage can
be implemented using network-attached storage (NAS) devices or distributed file systems.
Key features of file storage include:

84 | P a g e
  Shared access: Multiple clients or systems can access and modify files concurrently, making them suitable
for collaboration and shared file systems.
 File-level operations: File storage provides operations at the file level, such as read, write, and modify,
making it compatible with traditional file-based applications and workflows.
 Metadata support: File systems often support metadata attributes associated with files, such as
permissions, timestamps, and file attributes.
Options:
1. Amazon Elastic File System (EFS)
2. Azure Files
3. Google Cloud Filestore
Differences between them are as follows:

Storage Type Block Storage Object Storage File Storage

Data Structure Fixed-sized blocks Objects Hierarchical files

Access Method Low-level block access RESTful API File-level protocols

Data Access Random access Object-based access File-based access

Databases, VMs, high- Unstructured data, Shared file systems, file-

Use Cases
performance applications backups, media files based applications

Scalability Limited by device capacity Highly scalable Scalable

Depends on RAID or replication Depends on the file system

Redundancy Built-in redundancy
configurations and configurations

Metadata Limited metadata Rich metadata support Metadata support

Concurrent Concurrent access for

Limited shared access Shared access to files
Access objects

NFS, SMB, DFS

Protocols SAN, DAS RESTful API (e.g., S3)

Conclusion: Block storage offers low-level access and is commonly used for high-performance applications, object
storage provides scalability and flexibility for managing unstructured data, and file storage offers shared access
and compatibility with file-based applications. The choice among these storage types depends on the specific
requirements and characteristics of your system design.

Normalization Process in DBMS

Normalization Process in DBMS
Database Normalization is any systematic process of organizing a database schema such that no data redundancy
occurs and there is least or no anomaly while performing any update operation on data. In other words, it means
dividing a large table into smaller pieces such that data redundancy should be eliminated. The normalizing
procedure depends on the functional dependencies among the attributes inside a table and uses several normal
forms to guide the design process.
The Normalization Process Begins With the Following:
 First Normal Form (1NF): Ensures that each column contains only atomic values that cannot be divided,
and each record is unique.

85 | P a g e
  Second Normal Form (2NF): Includes 1NF and removes subsets of data that would apply for more than
one row and places that data in a separate table. It deals with a partial dependency example when a non-
key attribute depends on part of a composite primary key.
 Third Normal Form(3NF): This applies further normalization to the schema by removing transitive
dependencies, which are where the non-key attributes depend on other non-key attributes.
Normalization ensures that databases are structured efficiently, reducing redundancy. To master this process and
its applications in DBMS, the GATE CS Self-Paced Course offers practical examples and exercises on normalization
and other key concepts.
Besides these, BCNF is a stronger version of 3NF, developed by Raymond F. Boyce and Edgar F. Codd, which
handles some more cases of redundancy not dealt with by 3NF. Further normal forms like Fourth Normal Form
and Fifth Normal Form apply to the more complex scenarios for multi-valued dependencies and join
dependencies, respectively. These are also less commonly applied.
Boyce-Codd Normal Form (BCNF)
Boyce-Codd Normal Form, or BCNF for short, is an extension of the Third Normal Form, 3NF, in that it seeks to
eliminate certain types of redundancy that the latter does not catch. In BCNF, for a table to be said to be in BCNF,
it needs to have the following condition met: for any nontrivial functional dependency
X→Y, X must be a superkey.
X needs to be a superkey. That is, for every functional dependency of the table, on the left of that dependency, an
attribute or set of attributes should be a superkey of the table.
This requirement is stronger than that of 3NF, which only had a non-key attribute non-transitively dependent on a
primary key. BCNF takes care of situations where, even for a table in 3NF, redundancy would still arise whenever
there is added a dependency whose left-hand side is not a superkey, hence ensuring a higher level of
normalization and, therefore, reduced redundancy.
Example of BCNF Violation
Here’s a table illustrating a BCNF violation with the given example:
Original Table (BCNF Violation)
CourseID Instructor Room

CSE10
SMITH R101
1

CSE10
JOHNSON R102
2

CSE10
SMITH R101
3

CSE10
LEE R102
4

Functional Dependencies:
CourseID → Instructor
Instructor → Room
Explanation of BCNF Violation:
The functional dependency Instructor → Room indicates that the Room is determined by the Instructor.
However, Instructor is not a superkey of the table since it does not uniquely determine all attributes (it does
not determine CourseID). This causes a violation of BCNF.
Decomposition Into BCNF
To convert this table into BCNF, we decompose it into two separate tables:
1. CourseInstructor Table
CourseID Instructor

CSE101 Smith

86 | P a g e
CourseID Instructor

CSE102 Johnson

CSE103 Smith

CSE104 Lee

2. InstructorRoom Table
Instructor Room

Smith R101

Johnso
R102
n

Lee R103

Result
 In the CourseInstructor table, CourseID is a superkey, and it uniquely determines Instructor.
 In the InstructorRoom table, Instructor is a superkey, and it uniquely determines Room.
This decomposition satisfies BCNF since in both tables, every functional dependency has a superkey on its left
side.

Normalization Process in DBMS

Now, we are going to describe the process of Normalization by considering an Example. Let us look into that.
Normalization Process Example
In this example, we will look into that how we can normalize the database with the help of different Normal
Forms. We will look into each of the Normal Forms separately in this example.
Consider the table 1 shown below:

87 | P a g e
Full Name Institute Courses Result

Naveen
IIT Delhi DBMS, OS Pass
Kumar

Utkarsh Tiwari IIT Bombay CN. COA Fail

Utkarsh Tiwari IIT Kanpur OS Fail

Now, we are re-structuring the table according to the 1st Normal Form.
Rules of 1st Normal Form
 Each table should contain a single value.
 Each record needs to be unique.
Table 1 after applying 1st Normal Form:
Subjec
Full Name Institute t Result

Naveen Kumar IIT Delhi DBMS Pass

Naveen Kumar IIT Delhi OS Pass

Utkarsh Tiwari IIT Bombay CN Fail

Utkarsh Tiwari IIT Bombay COA Fail

Utkarsh Tiwari IIT Kanpur OS Fail

Consider the table 2 shown below:

Full Name Institute Subject Result

Utkarsh Tiwari IIT Bombay COA Fail

Utkarsh Tiwari IIT Kanpur OS Fail

Here, People having the same name are from different institutes. So, we require Full Name and Institute to
Identify a Row of the database. For this, we have to remove Partial Dependency.
Let’s look at the 2nd Normal Form.
Rules of 2nd Normal Form
 The table should be in 1NF.
 Primary Key does not functionally dependent on any subset of Candidate Key.
Table 1
ID Full Name Institute Result

1 Naveen Kumar IIT Delhi Pass

2 Utkarsh Tiwari IIT Bombay Fail

3 Utkarsh Tiwari IIT Kanpur Fail

88 | P a g e
Table 2
ID Subject

1 DBMS

1 OS

2 CN

2 COA

3 OS

Here, the Id in Table 2 is Foreign Key to the Id in Table 1. Now, we have to remove Transitive Functional
Dependency from our Table to Normalize our Database. A Transitive Functional Dependency basically tells us that
there is an indirect relationship between functional dependency.
Now, let us look at the 3rd Normal Form.
Rules of 3rd Normal Form
 The tables should be in 2NF.
 There will be no Transitive Dependency.
Table 1
ID Full Name Institute Result_ID

Naveen
1 IIT Delhi 1
Kumar

2 Utkarsh Tiwari IIT Bombay 2

3 Utkarsh Tiwari IIT Kanpur 2

Table 2
ID Subject

1 DBMS

1 OS

2 CN

2 COA

3 OS

Table 3
Result_ID Result

1 Pass

89 | P a g e
Result_ID Result

2 Fail

3 On Hold

Finally, Our Database is Normalized. From the above-mentioned example, we have reached our level of
Normalization. In fact, there are also some higher forms or next levels of Normalization. Now, we are going to
discuss them one by one.
Other Normal Forms
 Boyce-Codd Normal Form (BCNF): Sometimes, when the database is in the 3rd Normal Form, there exist
some anomalies in DBMS, like when more than one Candidate Keys is present in the Database. This has to
be removed under BCNF . BCNF is also called 3.5NF.
 4th Normal Form: Whenever a Database contains multivalued and independent data in two or more
tables, then the database is to be considered in the 4th Normal Form.
 5th Normal Form: Whenever a Database Table is not in 4NF, and we cannot divide it into smaller tables
keeping our data safe with us, then our Database is in 5th Normal Form.
Summary of Normalization in a Nutshell
Normal
Form Test Remedy (Normalization)

The relation should have no non-atomic attributes or Form a name relation for each non-
1NF
nested relations. atomic attribute or nested relation.

Decompose and set up a new relation

for each partial key with its dependent
For relations where the primary key contains multiple
attributes.
attributes, no non-key
2NF Make sure to keep a relationship with
attributes should be functionally dependent on a part of
the original primary key and any
the primary key.
attributes that are fully functionally
dependent on it.

The relation should not have a non-key attribute

Decompose and set up a relation that
functionally determined by another non-key attribute (or
includes the non-key attribute(s) that
3NF by a set of non-key attributes) i.e., there should be no
functionally determine(s) another non-
transitive dependency of a non-key attribute of the
key attribute (s).
primary key.

The relation should not have any attribute in Functional

Make sure that the left side of every
Dependency which is
BCNF functional dependency is a candidate
non-prime, the attribute that doesn’t occur in any
key.
candidate key.

The relation should not have a multi-value dependency

means it occurs when two attributes of a table are Decompose the table into two
4NF
independent of each other but both depend on a third subtables.
attribute.

The relation should not have join dependency means if a

Decompose all the tables into as many
table can be recreated by joining multiple tables and each
5NF as possible numbers in order to avoid
of the tables has a subset of the attributes of the table,
dependency.
then the table is in Join Dependency.

90 | P a g e
Conclusion
The process of normalization of databases will ensure that an efficient, organized, and consistent database is
created by avoiding any redundancy and anomalies during the update of data. Databases can be modeled into
normal forms starting from 1NF to BCNF and beyond in order to maintain the integrity of the data and improve
the performance of the database. Each normal form takes care of specific redundancies and dependencies which
finally result in a well-organized schema for accurate data management and retrieval.
Frequently Asked Questions on Normalization Process in DBMS – FAQs
What is database normalization?
Normalization is the method of setting the schema of the database so that it reduces redundancy and avoids
anomalies. This is done by breaking down big tables into smaller, more manageable bits.
What is Boyce-Codd Normal Form?
A higher form of 3NF. For all nontrivial functional dependencies, the left side will be superkey.
What is the purpose of First Normal Form?
1NF ensures that each column is atomic, having a single value for every record.
How is 2NF different from 1NF?
2NF builds upon 1NF by removing partial dependencies in which a non-key attributes depend on only part of a
composite primary key.
What is one of the most common problems avoided by 4NF?
4NF deals with multi-valued dependencies when two attributes are independent of each other but depend on a
third; thus, they should be decomposed into separate tables.

Denormalization in Databases
Denormalization in Databases
Denormalization is used to alter the structure of a database. Denormalization focuses on adding redundancy
which means combining multiple tables so that execute queries quickly. In this article, we’ll explore
Denormalization and how it impacts database design.
What is Denormalization in Databases?
Denormalization is a database optimization technique in which we add redundant data to one or more tables.
This can help us avoid costly joins in a relational database. Note that denormalization does not mean ‘reversing
normalization’ or ‘not to normalize’. It is an optimization technique that is applied after normalization.
Basically, The process of taking a normalized schema and making it non-normalized is called denormalization, and
designers use it to tune the performance of systems to support time-critical operations.
In a traditional normalized database, we store data in separate logical tables and attempt to minimize redundant
data. We may strive to have only one copy of each piece of data in a database.
For example, in a normalized database, we might have a Courses table and a Teachers table. Each entry in
Courses would store the teacherID for a Course but not the teacherName. When we need to retrieve a list of all
Courses with the Teacher’s name, we would do a join between these two tables.
In some ways, this is great; if a teacher changes his or her name, we only have to update the name in one place.
The drawback is that if tables are large, we may spend an unnecessarily long time doing joins on tables.
Denormalization, then, strikes a different compromise. Under denormalization, we decide that we’re okay with
some redundancy and some extra effort to update the database in order to get the efficiency advantages of fewer
joins.
What is a Database ?
A database is an organized collection of data or information that’s why it is also known as structured data.
Generally database is controlled by a database management system (DBMS) because by using DBMS you can
easily accessed, managed and updated the data in databases.
There are many types of database :
 No-SQL databases
 Relational databases
 In-memory databases
 Distributed Databases
 Data Warehouses
 Cloud databases
How is Denormalization Different From Normalization ?
Normalization and Denormalization both are the method which use in database but it works opposite to each
other. One side normalization is used for reduce or removing the redundancy which means there will be no
91 | P a g e
duplicate data or entries in the same table and also optimizes for data integrity and efficient storage, while
Denormalization is used for add the redundancy into normalized table so that enhance the functionality and
minimize the running time of database queries (like joins operation ) and optimizes for performance and query
simplicity.
In a system that demands scalability, like that of any major tech company, we almost always use elements of both
normalized and denormalized databases.
Advantages of Denormalization
 Improved Query Performance: Denormalization can improve query performance by reducing the number
of joins required to retrieve data.
 Reduced Complexity: By combining related data into fewer tables, denormalization can simplify the
database schema and make it easier to manage.
 Easier Maintenance and Updates: Denormalization can make it easier to update and maintain the
database by reducing the number of tables.
 Improved Read Performance: Denormalization can improve read performance by making it easier to
access data.
 Better Scalability: Denormalization can improve the scalability of a database system by reducing the
number of tables and improving the overall performance.
Disadvantages of Denormalization
 Reduced Data Integrity: By adding redundant data, denormalization can reduce data integrity and
increase the risk of inconsistencies.
 Increased Complexity: While denormalization can simplify the database schema in some cases, it can also
increase complexity by introducing redundant data.
 Increased Storage Requirements: By adding redundant data, denormalization can increase storage
requirements and increase the cost of maintaining the database.
 Increased Update and Maintenance Complexity: Denormalization can increase the complexity of
updating and maintaining the database by introducing redundant data.
 Limited Flexibility: Denormalization can reduce the flexibility of a database system by introducing
redundant data and making it harder to modify the schema.
Conclusion
Denormalization is the method which is used to add the redundancy so that execute the query quickly. It is used
for decrease the number of tables so that execute the query quickly (like joins operation ). Denormalization
improve the storage efficiency so that improve the query performance (like when read heavy systems ).
Denormalization has many benefits in some situations but it requires management so that avoid data
inconsistencies problems.

Differentiate between block, object, and file storage systems.

Aspect Block Storage Object Storage File Storage
Structure Fixed-size blocks Data with metadata & unique ID Files in directories
Access Low-level (via OS/apps) APIs File system protocols
Performance High (low latency) Moderate (high throughput) Moderate
Scalability Limited to clusters Highly scalable Limited
Best for Databases, VMs Backups, unstructured data File sharing, documents

Critique the effectiveness of scalability approaches in real-world applications.

Scalability is a critical factor in the design and operation of real-world applications, especially those
handling fluctuating workloads or growing user bases. Different scalability approaches—vertical scaling,
horizontal scaling, and hybrid scaling—each have strengths and limitations. Here's a critique of their
effectiveness in real-world applications:

1. Vertical Scaling (Scaling Up)

 Description: Increasing the resources (CPU, RAM, storage) of a single machine.

92 | P a g e
  Effectiveness:
o Strengths:
 Simpler to implement, requiring no changes to application architecture.
 Ideal for applications not designed for distributed environments.
 Can provide immediate performance improvements for resource-bound workloads.
o Weaknesses:
 Limited scalability: Physical limits on how much a single machine can be
upgraded.
 Single point of failure: If the machine fails, the entire application may go offline.
 Cost efficiency: High-end hardware can be disproportionately expensive compared
to the performance gain.
o Real-world Example:
 Small-scale relational databases often start with vertical scaling until reaching
hardware limits.

2. Horizontal Scaling (Scaling Out)

 Description: Adding more machines (servers) to distribute the workload.

 Effectiveness:
o Strengths:
 Offers virtually unlimited scalability in distributed systems.
 Enables high availability and fault tolerance (e.g., through redundancy).
 Cost-effective in cloud environments with pay-as-you-go models.
o Weaknesses:
 Complexity: Requires rearchitecting applications to support distributed
environments.
 Latency: Increased inter-node communication can lead to higher latencies.
 Consistency: Managing state and ensuring consistency across nodes can be
challenging.
o Real-world Example:
 Web applications like social media platforms (e.g., Facebook) rely on horizontal
scaling to handle billions of users.

3. Hybrid Scaling

 Description: Combines vertical and horizontal scaling strategies.

 Effectiveness:
o Strengths:
 Offers flexibility, allowing applications to benefit from the strengths of both
approaches.
 Balances cost and complexity by scaling up first, then out as needed.
 Useful for dynamic workloads where different scaling needs arise over time.
o Weaknesses:
 Operational complexity: Managing two scaling strategies increases system
administration overhead.
 Dependency on workload: Requires careful planning to determine when to switch
between scaling methods.
o Real-world Example:
 E-commerce platforms during peak events (e.g., Black Friday) use hybrid scaling
to handle both steady-state and sudden traffic surges.

93 | P a g e
4. Auto-scaling in Cloud Environments

 Description: Automatically adjusts resources based on real-time demand.

 Effectiveness:
o Strengths:
 Highly efficient in handling dynamic workloads.
 Reduces operational costs by scaling down during low demand.
 Ensures high availability and optimal performance during traffic spikes.
o Weaknesses:
 Latency in scaling: Can lead to temporary performance degradation during sudden
traffic surges.
 Dependency on accurate metrics: Ineffective if monitoring tools fail or provide
inaccurate data.
 Cost unpredictability: Unexpected scaling events can increase operational costs.
o Real-world Example:
 Streaming platforms like Netflix use auto-scaling to maintain performance during
popular content releases.

Develop a strategy for implementing database replication.

Implementing Database Replication: A Strategy

Database replication involves duplicating data from a primary database to one or more secondary
databases to improve performance, enhance fault tolerance, and ensure data availability. A well-planned
strategy is critical for effective implementation.

1. Define Objectives

Clearly outline the goals for replication to select the most appropriate approach:

 High Availability: Ensure continuous database service in case of primary failure.

 Load Balancing: Distribute read operations across replicas to reduce primary server load.
 Disaster Recovery: Maintain a copy of the database for backup and restoration.
 Geographical Distribution: Reduce latency for users in different regions.

2. Select the Replication Type

Choose a replication method based on system requirements:

A. Synchronous Replication

 Description: Ensures data consistency by writing changes to replicas simultaneously.

 Use Case: Applications where strong consistency is critical, such as financial systems.
 Trade-offs:
o Higher latency due to wait times for replica confirmation.
o Risk of performance degradation under heavy load.

B. Asynchronous Replication

94 | P a g e
  Description: Changes are written to replicas after committing on the primary database.
 Use Case: Applications prioritizing performance and availability over real-time consistency.
 Trade-offs:
o Faster write operations.
o Potential for data lag between primary and replicas.

C. Multi-Master Replication

 Description: Multiple nodes act as both primary and replica, allowing writes to any node.
 Use Case: Distributed systems with multiple data entry points.
 Trade-offs:
o Increased complexity due to conflict resolution requirements.

D. Hybrid Replication

 Description: Combines synchronous and asynchronous methods for specific use cases.
 Use Case: Systems requiring both consistency in critical operations and speed in others.

3. Choose Tools and Technology

Select a database and replication tool based on compatibility and requirements:

Relational Databases

 MySQL: Built-in replication with master-slave or multi-master configurations.

 PostgreSQL: Streaming replication and logical replication for custom use cases.
 SQL Server: Always On availability groups for high availability and disaster recovery.

NoSQL Databases

 MongoDB: Replica sets for automatic failover and distributed reads.

 Cassandra: Peer-to-peer replication model for scalability and fault tolerance.

Cloud-Based Solutions

 AWS RDS, Google Cloud SQL, or Azure SQL Database: Managed services with built-in
replication support.

4. Plan the Replication Topology

Define the structure and number of nodes in the replication setup:

 Single-Master, Multiple-Replica:
o One primary database for writes and multiple replicas for reads.
o Simplest setup for load balancing and availability.
 Multi-Master:
o Multiple nodes act as primary and replicate to each other.
o Requires conflict resolution for simultaneous updates.
 Cascading Replication:
o Secondary replicas serve as sources for other replicas.
o Reduces the load on the primary database.

95 | P a g e
  Geo-Distributed Replication:
o Nodes are distributed across geographical locations to reduce latency.
o Useful for global applications.

5. Implement and Configure Replication

 Step 1: Setup Primary Database:

o Ensure primary database is properly configured with sufficient resources.
o Enable binary logs (e.g., binlog for MySQL).
 Step 2: Configure Replicas:
o Initialize replicas by copying data from the primary database (e.g., using a snapshot or
backup).
o Configure replication settings (e.g., replication user, replication log position).
o Tools: mysqldump, pg_basebackup, or MongoDB’s initial sync.
 Step 3: Test Connectivity:
o Ensure replicas can communicate with the primary.
o Verify network configurations and permissions.
 Step 4: Monitor Data Flow:
o Ensure data is replicating correctly by comparing primary and replica data.
o Use built-in replication status commands (e.g., SHOW SLAVE STATUS in MySQL).

6. Address Conflict Resolution

 Read-Only Replicas:
o Simplify conflict resolution by disallowing writes on replicas.
 Conflict Detection and Resolution:
o Use versioning or timestamps for resolving conflicts in multi-master replication.
o Automate conflict resolution or design application-level logic.

7. Optimize for Performance

 Read-Write Splitting:
o Direct read operations to replicas and write operations to the primary.
o Use database drivers or middleware for query routing.
 Replica Lag Handling:
o Monitor replica lag and ensure applications can tolerate delays.
o Use tools like pt-heartbeat or built-in monitoring features.

8. Implement Monitoring and Alerts

 Tools:
o Prometheus + Grafana: Monitor metrics such as replication lag, network bandwidth, and
replica health.
o Database-Specific Monitoring:
 MySQL: SHOW SLAVE STATUS.
 PostgreSQL: pg_stat_replication.
 MongoDB: rs.status().
96 | P a g e
  Alerts:
o Notify administrators in case of replication lag, node failure, or synchronization issues.

9. Conduct Testing

 Simulate primary database failure and verify failover mechanisms.

 Test data consistency across replicas under different workloads.
 Measure the impact of replication lag on application performance.

10. Regular Maintenance and Scaling

 Periodically clean replication logs to prevent disk space issues.

 Re-evaluate topology and add replicas as needed for scaling.
 Ensure replicas are updated during database schema changes.

Propose a comprehensive database storage solution for a large enterprise.

Comprehensive Database Storage Solution for a Large Enterprise

Designing a database storage solution for a large enterprise requires careful consideration of scalability,
performance, fault tolerance, security, and cost-efficiency. Below is a proposed solution with a hybrid
approach that leverages multiple database types and storage tiers to address the diverse needs of an
enterprise.

1. Key Requirements

A. Scalability

 Handle large volumes of data and growing workloads.

 Support horizontal and vertical scaling.

B. High Availability (HA)

 Ensure uninterrupted operations with minimal downtime.

 Provide disaster recovery mechanisms.

C. Performance

 Optimize for fast read and write operations.

 Support real-time analytics and batch processing.

D. Data Types

 Structured: Relational data for transactions.

 Semi-structured: JSON/XML for APIs.
 Unstructured: Logs, multimedia, and IoT data.

97 | P a g e
E. Security and Compliance

 Implement robust encryption and access controls.

 Comply with regulations like GDPR, HIPAA, or PCI DSS.

F. Cost Optimization

 Use tiered storage based on access frequency.

2. Architecture Overview

A. Database Layers

1. Transactional Databases (OLTP):

o Purpose: Handle high-volume, low-latency operations.
o Database: Relational Database Management System (RDBMS) such as PostgreSQL,
MySQL, or Oracle.
o Features:
 ACID compliance for data integrity.
 Horizontal scaling via sharding or read replicas.
 Primary use cases: Financial transactions, ERP systems.
2. Analytical Databases (OLAP):
o Purpose: Perform complex queries and aggregations on large datasets.
o Database: Columnar databases like Snowflake, Google BigQuery, or Amazon Redshift.
o Features:
 Optimized for read-heavy operations.
 Support for parallel query execution.
 Primary use cases: Business intelligence, data warehousing.
3. NoSQL Databases:
o Purpose: Handle semi-structured and unstructured data.
o Database: MongoDB (document-based), Cassandra (wide-column), or Redis (key-value).
o Features:
 Schema-less design for flexibility.
 High throughput for distributed systems.
 Primary use cases: APIs, IoT, and real-time data feeds.
4. Graph Databases:
o Purpose: Represent and query relationships between entities.
o Database: Neo4j or Amazon Neptune.
o Features:
 Optimized for traversing nodes and edges.
 Primary use cases: Social networks, recommendation engines.

B. Storage Tiers

1. Hot Storage:
o Purpose: Store frequently accessed, performance-critical data.
o Technology: NVMe SSDs or cloud services like Amazon EBS, Azure Premium Disks.
o Use Cases: Current transactions, session data.
2. Warm Storage:
o Purpose: Store less frequently accessed data with moderate performance needs.
o Technology: HDDs or cloud-based object storage like Amazon S3 Standard.

98 | P a g e
 o Use Cases: Historical data, backups.
3. Cold Storage:
o Purpose: Archive rarely accessed data for long-term storage.
o Technology: Tape drives, Amazon S3 Glacier, or Azure Archive Storage.
o Use Cases: Compliance archives, audit logs.

3. Data Partitioning and Distribution

A. Horizontal Partitioning (Sharding):

 Split data across multiple nodes to distribute load.

 Example: Partition user data by region (e.g., North America, Europe, Asia).

B. Vertical Partitioning:

 Separate columns or features into different tables or systems.

 Example: Store user credentials in a secure database and user preferences in NoSQL.

C. Data Replication:

 Use master-slave or multi-master replication for fault tolerance and load distribution.
 Example: Use read replicas for analytics queries to reduce the load on the primary database.

4. Backup and Disaster Recovery

A. Backup Strategy:

 Full backups weekly and incremental backups daily.

 Use tools like AWS Backup or Azure Backup for automation.

B. Disaster Recovery:

 Maintain geographically distributed replicas to minimize downtime.

 Use technologies like PostgreSQL’s Streaming Replication or MongoDB Atlas Global Clusters.

C. Testing:

 Conduct regular failover and restore testing to validate the disaster recovery plan.

5. Security and Access Control

A. Encryption:

 Encrypt data at rest using AES-256 and data in transit using TLS.
 Use cloud-native Key Management Services (KMS) for key management.

B. Authentication and Authorization:

 Implement role-based access control (RBAC).

99 | P a g e
  Use federated authentication with Single Sign-On (SSO) and multi-factor authentication (MFA).

C. Compliance:

 Ensure audit trails are maintained for data access and modifications.
 Use tools like Splunk or Datadog for security monitoring.

6. Monitoring and Maintenance

A. Performance Monitoring:

 Use tools like Prometheus + Grafana or cloud-native monitoring services.

 Track metrics like query performance, disk I/O, and replication lag.

B. Capacity Planning:

 Regularly analyze storage usage and scale horizontally or vertically as needed.

 Use autoscaling features in cloud services for dynamic workloads.

C. Updates and Patching:

 Automate updates using managed services or tools like Ansible.

 Ensure minimal downtime with rolling updates or blue-green deployments.

7. Example Enterprise Setup

Scenario: A global e-commerce platform.

Use Case Database Type Storage Tier Example Tool

User Transactions Relational (OLTP) Hot Storage PostgreSQL on AWS RDS
Product Recommendations Graph Database Hot Storage Neo4j
Clickstream Data NoSQL (Wide Column) Warm Storage Apache Cassandra
Business Intelligence Columnar (OLAP) Warm Storage Amazon Redshift
Archived Logs Object Storage Cold Storage Amazon S3 Glacier
Disaster Recovery Multi-Region Replicas All Tiers AWS Aurora Global DB

8. Benefits of the Proposed Solution

 Performance: Optimized storage tiers for different access patterns.

 Scalability: Horizontal scaling and sharding for growing datasets.
 Resilience: Robust replication and disaster recovery strategies.
 Security: Strong encryption and role-based access controls.
 Cost-Efficiency: Tiered storage minimizes expenses for archival data.

Conclusion

100 | P a g e
This comprehensive solution provides a modular, scalable, and secure database storage strategy tailored
for large enterprises. By leveraging a combination of database types, storage tiers, and modern tools, it
ensures high performance, reliability, and cost-effectiveness.

Core components of system design, and how do they contribute to creating an

effective system architecture

Core Components of System Design and Their Contributions

System design involves creating a blueprint for building an efficient, scalable, and maintainable software
system. The core components of system design define the structure and behavior of a system and
contribute to its effectiveness as follows:

1. Requirements Analysis

 Description: Identify functional (features, user stories) and non-functional requirements

(scalability, performance, availability).
 Contribution:
o Ensures the system addresses the actual needs of users and stakeholders.
o Helps prioritize features and design trade-offs.
o Example: For an e-commerce platform, ensure fast load times (non-functional) and order
processing (functional).

2. System Architecture

 Description: Defines the overall structure, including components, their relationships, and
communication mechanisms.
 Contribution:
o Provides a high-level view of the system, ensuring modularity and ease of understanding.
o Ensures alignment with technical and business goals.
o Example: A microservices architecture for an e-commerce system to allow independent
scaling of services like inventory and payments.

3. Data Management

 Description: Includes the design of databases, data flow, storage mechanisms, and access
patterns.
 Contribution:
o Ensures efficient data storage and retrieval.
o Guarantees data integrity, consistency, and availability.
o Example: Using relational databases for transactional consistency and NoSQL databases
for high-speed, scalable read operations.

101 | P a g e
4. Scalability

 Description: The system’s ability to handle growth in users, data, or traffic.

 Contribution:
o Ensures performance under increasing load.
o Enables cost-effective scaling through horizontal (adding more servers) or vertical
(upgrading hardware) scaling strategies.
o Example: Implementing load balancers and caching layers to handle traffic spikes.

5. Reliability and Fault Tolerance

 Description: Mechanisms to ensure the system remains operational despite failures.

 Contribution:
o Improves user trust by minimizing downtime.
o Ensures graceful degradation during partial failures.
o Example: Using redundant servers and databases with failover strategies.

6. Performance Optimization

 Description: Techniques to reduce response times, improve throughput, and optimize resource
usage.
 Contribution:
o Provides a better user experience with fast response times.
o Minimizes resource wastage.
o Example: Using caching (e.g., Redis) for frequently accessed data and optimizing database
queries.

7. Security

 Description: Measures to protect the system from unauthorized access, data breaches, and attacks.
 Contribution:
o Safeguards sensitive user data and maintains trust.
o Ensures compliance with regulatory standards like GDPR or HIPAA.
o Example: Using HTTPS, encryption (e.g., AES-256), and access controls like OAuth.

8. APIs and Communication Protocols

 Description: Defines how components within the system or external clients interact.
 Contribution:
o Ensures seamless data exchange between components and third-party systems.
o Facilitates modular and reusable design.
o Example: RESTful APIs for client-server communication and gRPC for service-to-service
communication.

9. User Interface (UI) and User Experience (UX)

102 | P a g e
  Description: Design of front-end interfaces and interactions.
 Contribution:
o Improves user engagement with intuitive design.
o Enhances accessibility and usability.
o Example: Responsive web design for e-commerce sites catering to desktop and mobile
users.

10. Deployment and DevOps

 Description: Strategies for deploying and maintaining the system, including CI/CD pipelines.
 Contribution:
o Automates deployment, reducing errors and downtime.
o Ensures quick rollbacks in case of failures.
o Example: Using Docker and Kubernetes for containerized deployments.

11. Monitoring and Observability

 Description: Tools and techniques for tracking system health and performance.
 Contribution:
o Helps detect and resolve issues proactively.
o Provides insights for capacity planning and optimization.
o Example: Using Prometheus and Grafana for monitoring and alerting.

12. Cost Management

 Description: Optimizing resource usage to balance performance with cost.

 Contribution:
o Reduces operational expenses without compromising quality.
o Enables efficient scaling based on usage patterns.
o Example: Using spot instances on cloud platforms for cost-sensitive batch processing.

How These Components Create an Effective Architecture

1. Interconnected Design:
o Each component supports others, creating a cohesive and functional system. For example,
scalability strategies (like load balancing) must align with system architecture and data
management.
2. Alignment with Goals:
o Requirements analysis ensures that the architecture meets business objectives, whether
focusing on performance, reliability, or cost-efficiency.
3. Resilience and Adaptability:
o Security, reliability, and fault tolerance ensure the system remains operational under stress,
while flexibility supports future growth.
4. User-Centric Approach:
o UI/UX and performance optimization focus on delivering a seamless experience to end
users.
5. Efficiency and Automation:
103 | P a g e
 o Deployment pipelines and monitoring tools enable quick iteration and fault recovery,
making the system adaptable to changing requirements.

Conclusion

The core components of system design are interdependent and collectively ensure that the system is
scalable, reliable, secure, and user-friendly. An effective architecture results from carefully balancing
these components to meet the system's technical and business requirements.

--------------------------------------- --------------------------
Students should know FAQ for placement activities.
************************--**********************************
 Functional and Non-Functional Requirements.
 Structured Analysis and Structured Design (SA/SD).
 Horizontal and Vertical Scaling in system design.
 Components of system design.
 System Design Strategy.
 Role of Load Balancer in system design.
 System Design Life Cycle (SDLC).
 Concept of Database Sharding in system design.
 Primary bottlenecks that hurt the scalability of an application.
 Different types of storage systems used in system design (Block, Object, File).
 Key elements of Object-Oriented Analysis and Design.
 Scalability approaches for an application.
 Criteria for choosing between SQL and nosql databases.
 Structured analysis approach to system design.
 Factors affecting latency and throughput in system design.
 Advantages and disadvantages of database replication.
 Impact of load balancing on system performance.
 Sharding is used to improve database performance.
 Redundancy contribute to the availability of a system, and what are its potential downsides
 Comprehensive database storage solution for a large enterprise.
 Key Components of Availability, explain its Measuring and Ensuring Availability
 Core components of system design, and how do they contribute to creating an effective system
architecture.
 Components such as databases, user interfaces, and apis interact within a system design
 Essential security measures that should be considered during the system design phase to protect
against common threats

------------------------ -------------------- ----------------------------------------

104 | P a g e