Week 10 – System Design

Falcon, Carl Roehl Joseph S.

BSIT_MWA, 3rd Year
October 10, 2024
Systems Integration & Architecture

1. What is system design?

 The process of specifying a system's architecture, parts, modules, interfaces,
and data flows in order to meet predetermined specifications is called system
design. It is an important stage in network architecture, hardware engineering,
and software development. System design, to put it simply, is a blueprint that
directs how various components of a system will interact and work together to
accomplish desired goals.

Key Aspects of System Design:

1. High-Level Design (HLD):
o Focuses on overall architecture and big-picture decisions.
o Defines components and their relationships.
o Provides an overview of data flow, communication protocols, and system
boundaries.
o Examples include client-server architecture, microservices, and APIs.
2. Low-Level Design (LLD):
o Focuses on the detailed implementation of system components.
o Includes specific algorithms, database schema, and the logic inside
modules.
o Describes how individual components work and how they interact with
others.
3. Key Elements in System Design:
o Scalability: Can the system handle growing amounts of data or users
efficiently?
o Reliability: How does the system ensure that it functions correctly even
under failure conditions?
o Maintainability: Is the system easy to maintain, modify, or upgrade?
o Performance: Does the system meet performance expectations in terms
of speed, latency, or resource usage?
o Security: How does the system protect data and prevent unauthorized
access?

4. System Design Process:

 o Requirements Gathering: Understand functional and non-functional
requirements.
o Defining Components: Break the system into smaller, modular
components (e.g., services, databases).
o Choosing Technologies: Decide on the technology stack (programming
languages, frameworks, databases).
o Designing Data Flow: Determine how data will move through the system
(e.g., API interactions, message queues).
o Establishing Communication: Define the protocols and interfaces for
communication between components (e.g., REST, GraphQL).
o Security Considerations: Implement measures to ensure confidentiality,
integrity, and availability.
5. Types of Systems:
o Monolithic Systems: Single-tiered architectures where components are
tightly coupled.
o Distributed Systems: Systems where components are spread across
multiple machines or networks (e.g., cloud-based services).
o Microservices Architecture: Systems made up of small, independent
services that communicate over a network.
2. What are the system design processes? (Describe and list all the activities in
each design process)

The system design process involves multiple stages and activities

aimed at building a system that meets specific requirements in terms
of functionality, performance, and scalability. These processes are
divided into high-level design (HLD) and low-level design (LLD).
Each stage follows a structured approach to ensure the system is well-
designed and can be implemented efficiently.
Here’s an overview of the key processes in system design and the
activities involved in each:
1. Requirements Gathering and Analysis
This is the initial phase, where the system's requirements are collected
and analyzed. It involves identifying both functional and non-
functional requirements.
Activities:
 Functional Requirements Analysis:
o Understand what the system is supposed to do.
o Example: User authentication, file uploads, and order processing.
 Non-Functional Requirements Analysis:
o Address performance, scalability, security, availability, etc.
o Example: System should handle 1,000 concurrent users,
response time should be under 1 second.
 Use Case and User Stories:
o Define specific use cases that describe how users will interact
with the system.
 Prioritization:
o Prioritize requirements based on business needs and technical
feasibility.
 2. High-Level Design (HLD)
At this stage, the architecture of the system is created. The focus is on
defining the big picture of how the system will function as a whole, its
components, and how they interact.
Activities:
 System Architecture Definition:
o Decide the architectural style: Monolithic, Microservices, Client-
Server, etc.
 Component Design:
o Break down the system into major components or modules.
o Example: Frontend, Backend, Database, API Gateway, Cache.
 Data Flow and Control Flow:
o Design the flow of data between components and users.
o Example: How the data moves from the user to the backend, and
how responses are generated.
 Technology Selection:
o Choose the technology stack (e.g., programming languages,
databases, frameworks).
o Example: React for frontend, Node.js for backend, PostgreSQL for
database.
 Database Design (High-Level):
o Decide the type of database to use (SQL, NoSQL, Graph
database).
 API Design (High-Level):
o Outline the major APIs and services for interaction between
system components.
o Example: RESTful API, GraphQL.
 Security Considerations (High-Level):
o Identify security risks and implement strategies (e.g.,
authentication, encryption).
 Deployment Strategy:
o Define how the system will be deployed (e.g., cloud
infrastructure, on-premises servers).

3. Low-Level Design (LLD)

This process deals with the detailed design of system components,
focusing on how individual modules or features will be implemented.
Activities:
 Detailed Module Design:
o Break down each high-level component into smaller, more
specific modules.
o Example: In the backend, breaking the "user service" into
registration, login, and profile modules.
 Database Schema Design:
o Create detailed database schema (tables, indexes, relationships).
o Example: Defining the structure of the "Users" table, fields like
name, email, and password.
 Class and Object Design:
o For object-oriented systems, define classes, methods, and
attributes.
o Example: Creating a User class with methods like login() and
register().
 Algorithm Design:
o Define algorithms to solve specific problems within the system.
o Example: Sorting user search results based on relevance.
 API Design (Low-Level):
o Define the exact endpoints, input/output formats, and error
handling for APIs.
o Example: /api/v1/users/login endpoint with POST method and
JSON input.
 Interface Design:
o Specify how modules will interact with each other, including data
formats and protocols.
o Example: JSON data exchange between the frontend and
backend.
 Error Handling and Logging:
o Define how the system will handle errors and log them for future
debugging.

4. Prototyping (Optional)
This is an optional phase where a small, working model of the system
is built to test the feasibility of the design.
Activities:
 Build a Prototype:
o Develop a simplified version of the system to test key
components.
 User Feedback:
o Gather feedback from stakeholders or users based on the
prototype.
 Iteration:
o Refine the design based on feedback and issues encountered
during prototyping.

5. Design Validation
In this phase, the design is validated to ensure it meets the system's
requirements. The aim is to identify and resolve any potential design
issues before implementation.
Activities:
 Design Review:
 o Conduct design reviews with stakeholders and team members to
verify the design against the requirements.
 Feasibility Study:
o Assess whether the system design is feasible in terms of budget,
technology, and timeline.
 Performance Evaluation:
o Evaluate the performance characteristics of the system, such as
expected load, latency, and throughput.
 Security Review:
o Conduct security audits to ensure the system design addresses
security requirements.

6. Implementation Planning
Once the design is validated, planning for the actual system
implementation takes place.
Activities:
 Implementation Strategy:
o Break down the system design into tasks and assign them to
development teams.
 Timeline Estimation:
o Estimate time for developing each component or module.
 Milestone Definition:
o Define key milestones for progress tracking (e.g., alpha version,
beta version, final release).

7. Monitoring and Iteration

Even after the system is implemented, continuous monitoring and
iteration are required to ensure the system functions properly and can
be improved over time.
 Activities:
 Monitoring:
o Monitor system performance in production to ensure it meets the
expected load and requirements.
 Feedback Collection:
o Collect feedback from users and stakeholders to identify any
issues or improvements needed.
 Iteration:
o Continuously iterate on the system design based on new
requirements, feedback, or performance issues.

Summary of System Design Process:

1. Requirements Gathering and Analysis
2. High-Level Design (HLD)
3. Low-Level Design (LLD)
4. Prototyping (Optional)
5. Design Validation
6. Implementation Planning
7. Monitoring and Iteration
Each of these phases contributes to building a robust, scalable, and
maintainable system by addressing different aspects of system design
from architecture to detailed module implementation.
3. Types of system design. (Describe and list some of the characteristics of each
type of system design)

According to the size, complexity, and needs of the system being designed, there
are various forms of system design. Generally speaking, there are three
categories of system design: architectural, logical, and physical. These divisions
deal with different levels of abstraction, such as software, hardware, and
architecture.

Here are the primary types of system design, along with their characteristics:
1. Architectural Design (High-Level Design)
This type focuses on the overall structure of the system, defining the major
components and how they interact. It provides a blueprint of the system's
architecture without delving into the specifics of individual modules.
Characteristics:
 Component-Based: Defines the main components (e.g., frontend, backend,
database) and their interactions.
 System Boundaries: Specifies the boundaries of the system and what lies
outside (e.g., external services or third-party APIs).
 Communication Patterns: Outlines how components will communicate
(e.g., REST APIs, message queues).
 Technology Stack: High-level decisions on technologies (e.g., cloud vs on-
premise, SQL vs NoSQL).
 Deployment Strategy: Includes deployment environments (e.g., cloud
infrastructure, distributed architecture).
Examples:
 Monolithic Architecture: A single-tier, tightly coupled system where all
components are interconnected in one large application.
 Microservices Architecture: A design where components are small,
independent services that communicate over the network.
 Client-Server Architecture: Separates the system into clients (users) and
servers (which provide services or data).

2. Logical Design
 This focuses on the functionality and behavior of the system. It defines the
relationships between various system components, modules, and their
functions, but abstracts away from physical implementations.
Characteristics:
 Data Flow Diagrams (DFD): Describes how data flows through the system,
between users, applications, and storage.
 Entity-Relationship Diagrams (ERD): Illustrates relationships between
data entities (e.g., user, order, product) and their attributes.
 Process Logic: Defines the rules and conditions governing the system’s
behavior (e.g., how an order is processed).
 Abstract Representation: Focuses on what the system does, not how it’s
implemented.
Examples:
 Use Case Diagrams: Describes the interactions between users and the
system.
 State Diagrams: Show how the system behaves in different states (e.g.,
pending, processed, shipped).
 Class Diagrams: For object-oriented systems, shows the classes and their
relationships.

3. Physical Design
This deals with the physical aspects of the system, such as hardware,
storage, and networks. It defines how the system will be physically
implemented, including server setups, data storage mechanisms, and
network configurations.
Characteristics:
 Hardware Specifications: Determines the physical components such as
servers, databases, load balancers, etc.
 Network Design: Focuses on how the system will be connected, including IP
addresses, subnets, firewalls, and routing.
 Storage Design: Specifies where and how data will be stored (e.g., local
disks, cloud storage, RAID).
 Backup and Recovery Plans: Defines strategies for data redundancy,
backup, and disaster recovery.
 Performance Optimization: Focuses on optimizing resource allocation,
including CPU, memory, and storage space.
 Examples:
 Server Configuration: Deciding on the number of servers, load balancing
strategies, and distributed systems setup.
 Data Centers: Deciding whether to host the system on-premise or on cloud
platforms (e.g., AWS, Azure).
 Physical Data Models: Detailing the actual physical storage mechanisms
and database configurations.

4. Distributed System Design

This design type focuses on systems where components are distributed
across multiple machines or geographic locations, allowing them to work
together as a cohesive unit.
Characteristics:
 Scalability: Distributed systems are designed to scale horizontally by adding
more machines (nodes) as the load increases.
 Fault Tolerance: Designed to handle node failures gracefully, often using
replication and failover techniques.
 Consistency and Availability: Uses CAP theorem to trade off between
consistency, availability, and partition tolerance.
 Communication Protocols: Uses various communication protocols (e.g.,
HTTP, gRPC, message queues) to coordinate between distributed nodes.
 Data Replication: Data is often replicated across nodes to ensure
availability and fault tolerance.
Examples:
 Peer-to-Peer Systems: Each node in the system acts as both a client and a
server, like in file-sharing networks.
 Cloud Services: Systems built across multiple data centers using cloud
providers like AWS or Azure.
 Content Delivery Networks (CDNs): Distributed systems designed to
serve static content from locations closest to the end-users.

5. Data-Centric System Design

This type of design focuses on how data is stored, accessed, and managed
within the system. It includes database design, data access patterns, and
data storage strategies.
 Characteristics:
 Data Modeling: Defines the structure of data entities and their relationships
(e.g., using relational databases or NoSQL).
 Data Storage: Focuses on choosing the right type of database (SQL vs
NoSQL, flat files, object storage).
 Data Access Patterns: Optimizes how data is accessed and retrieved (e.g.,
indexing, caching).
 Data Integrity: Ensures data is accurate, consistent, and reliable across
various operations.
 Data Scalability: How the system handles large volumes of data (e.g.,
sharding, partitioning).
Examples:
 Relational Database Design: Using SQL databases with normalized data
structures.
 NoSQL Database Design: Using document, key-value, or graph databases
for unstructured or semi-structured data.
 Data Lakes: Centralized repositories for storing large volumes of raw data.

6. Security System Design

This type of design focuses on the security aspects of a system, addressing
how the system protects itself from threats, unauthorized access, and data
breaches.
Characteristics:
 Authentication and Authorization: Implement mechanisms to verify user
identity (authentication) and control access to resources (authorization).
 Encryption: Uses encryption for data at rest and in transit to ensure data
privacy.
 Firewalls and Intrusion Detection Systems: Protect the system from
external attacks and monitor for suspicious activity.
 Data Privacy Compliance: Ensures the system complies with legal
regulations (e.g., GDPR, HIPAA) for data privacy and protection.
 Vulnerability Management: Regular security audits, vulnerability scans,
and penetration testing.
Examples:
 OAuth 2.0: A standard for secure user authentication and authorization.
 SSL/TLS: Ensures secure communication between clients and servers using
encryption.
 Role-Based Access Control (RBAC): Controls access based on predefined
roles within the system.

7. User Interface (UI) Design

This type focuses on the design of user interfaces for software
applications, ensuring they are intuitive, user-friendly, and provide a smooth
experience for end-users.
Characteristics:
 Usability: Focuses on ensuring the system is easy to use and navigate.
 Accessibility: Ensures the interface is accessible to users with disabilities.
 Consistency: Designs consistent UI elements across the system for a unified
look and feel.
 User Experience (UX): Prioritizes how users interact with the system to
ensure satisfaction and ease of use.
 Responsiveness: Ensures the interface adapts well to different screen sizes
(mobile, desktop).
Examples:
 Wireframes: Low-fidelity sketches of user interfaces.
 Mockups: High-fidelity visual representations of the system’s interface.
 Prototypes: Interactive versions of the interface for testing user
interactions.

Summary of Types of System Design:

1. Architectural Design: Focuses on high-level system structure, component
interaction, and overall architecture.
2. Logical Design: Describes system functionality, data flow, and process
logic, abstracting implementation details.
3. Physical Design: Defines hardware, storage, networks, and physical system
implementation.
4. Distributed System Design: Focuses on systems with components
distributed across multiple machines or locations.
5. Data-Centric System Design: Focuses on data storage, access, and
management strategies.
6. Security System Design: Focuses on protecting the system from threats,
unauthorized access, and data breaches.
7. User Interface (UI) Design: Focuses on creating user-friendly, accessible,
and visually appealing interfaces.

4. DFD vs ERD (Describe, list all the components, and give at least one example
per diagram)
Data Flow Diagram (DFD) vs Entity Relationship Diagram (ERD)
Two separate types of diagrams are used in system design to describe
different parts of a system's data and structure: entity relationship diagrams
(ERD) and data flow diagrams (DFD). While both are necessary instruments,
their functions and parts differ.
Here’s a detailed comparison of DFD and ERD, their components, and
examples for each.
1. Data Flow Diagram (DFD)
A Data Flow Diagram (DFD) is a graphical representation used to illustrate
the flow of data within a system, highlighting how data moves between
processes, external entities, data stores, and users. DFDs focus on how data
moves through the system and where it is stored or transformed.
Components of DFD:
1. Processes:
o Represent activities or tasks where data is processed.

o Drawn as circles or rounded rectangles.

o Example: A "Process Payment" system.

2. Data Flows:
o Arrows that show the movement of data between processes, data
stores, and external entities.
o Example: A flow of "Customer Details" from the customer to a "Create
Account" process.
3. Data Stores:
 o Represent places where data is stored for future use.

o Drawn as two parallel lines.

o Example: A "Customer Database" or "Order Records."

4. External Entities (Sources/Sinks):

o Represent outside systems, users, or organizations that interact with
the system.
o Drawn as rectangles or squares.

o Example: A "Customer" or "Third-Party Payment Gateway."

Levels of DFD:
 Level 0 (Context Diagram): The highest level, representing the entire
system as a single process with external entities interacting with it.
 Level 1, 2, ... N: More detailed breakdowns of the system processes.
Example of DFD:
Context Diagram (Level 0): Imagine a basic e-commerce system where
customers can place orders, and the system processes them.
 External Entity: Customer
 Process: "Order Processing"
 Data Flow: Order Details flow from the customer to the process.
 Data Store: Orders Database stores the processed orders.

2. Entity Relationship Diagram (ERD)

 An Entity Relationship Diagram (ERD) is a diagram that illustrates the
relationships between entities in a database system. It focuses on what
data is stored and how various entities relate to one another, making it
particularly useful for database design.
Components of ERD:
1. Entities:
o Represent objects or concepts in the system that have data stored
about them.
o Drawn as rectangles.

o Example: "Customer," "Order," "Product."

2. Attributes:
o Represent characteristics or properties of an entity.

o Drawn as ovals connected to the entity.

o Example: "Customer Name," "Order Date," "Product Price."

3. Relationships:
o Show how entities are related to each other (e.g., one-to-one, one-to-
many, many-to-many).
o Drawn as diamonds connecting entities.

o Example: A "Customer" can "place" an "Order."

4. Primary Key (PK):

o A unique identifier for each entity, often underlined in the entity box.

o Example: "Customer ID" or "Order ID."

5. Foreign Key (FK):

o An attribute that creates a link between two entities.

o Example: "Customer ID" in the "Order" entity to reference a customer.

6. Cardinality:
o Specifies the relationship between entities in terms of quantity (one-to-
one, one-to-many, etc.).
o Example: A customer can place many orders, but an order is placed by
only one customer (one-to-many relationship).
Example of ERD:
 In an e-commerce system, we can represent customers, orders, and
products using an ERD.
 Entities: Customer, Order, Product
 Attributes: Customer has attributes like CustomerID, Name, Email. Order
has OrderID, OrderDate, etc.
 Relationships: A customer can place many orders (one-to-many), and an
order can contain many products (many-to-many).

 Customer (1-to-many) Order: A customer can place many orders.

 Order (many-to-many) Product: An order can contain multiple products,
and a product can appear in multiple orders (resolved by an intermediary
table like "OrderItems").
Key Differences between DFD and ERD:
Summary and Usage:
 DFD is ideal for understanding how data flows in a system, mapping
out processes, and visualizing how inputs are transformed into
outputs. It helps in system functionality design and process
understanding.
 ERD is crucial for database design, allowing designers to represent
entities and their relationships. It’s useful when defining the data
model and ensuring data integrity and relationships.
Each diagram serves a distinct role in the system design process. DFDs
are generally used to describe process flow, while ERDs are more focused
on data storage and structure. Both diagrams are complementary and
essential for building a well-structured and functioning system.

5. Flowchart (DFD vs ERD (Describe, list all the common symbols, and give at
least one example)
Flowchart vs. DFD vs. ERD
Systems can be modelled and designed using graphical tools such as
flowcharts, data flow diagrams (DFD), and entity relationship diagrams (ERD).
They employ distinct symbols to depict their elements, though, and serve
different goals.

Here’s a detailed comparison between Flowcharts, DFDs, and ERDs, along

with a description of their symbols and examples.

1. Flowchart
A flowchart is a diagram that represents a process or workflow. It depicts
the sequence of steps or operations involved in a system, program, or
process. Flowcharts are commonly used for understanding, analyzing, and
documenting processes, providing a simple and visual way to map tasks and
decision points.
Common Flowchart Symbols:
1. Process (Action):
o Represented as a rectangle.

o Describes a step or task in the process.

o Example: "Send email" or "Calculate total."

2. Decision:
o Represented as a diamond.

o Represents a branching point where a decision needs to be made,

typically with Yes/No or True/False outcomes.
o Example: "Is payment approved?"

3. Start/End (Terminator):
o Represented as an oval or a pill shape.

o Indicates the beginning or end of a process.

o Example: "Start process" or "End process."

4. Data Input/Output:
o Represented as a parallelogram.

o Represents input to or output from a process.

o Example: "Enter customer data" or "Display receipt."

5. Arrow (Flow Line):

o Shows the direction of the flow from one step to another.

6. Document:
o Represented as a rectangle with a wavy base.

o Indicates a document generated during the process.

o Example: "Generate invoice."

Example of Flowchart:
This flowchart illustrates a simple online order processing system.
 2. Data Flow Diagram (DFD)
A DFD focuses on representing how data flows through a system. It
illustrates the system’s processes, external entities, data stores, and how
data moves between them. DFDs help in understanding the data movement
and processing logic, but do not define the details of decision-making
processes as seen in flowcharts.
Common DFD Symbols:
1. Process:
o Represented as a circle or rounded rectangle.

o Describes a transformation or manipulation of data.

o Example: "Process Order" or "Calculate Invoice."

2. Data Flow:
o Represented as an arrow.

o Shows the direction of data movement between entities, processes,

and data stores.
 o Example: "Customer Details" or "Order Information."

3. Data Store:
o Represented as two parallel lines.

o Indicates where data is stored in the system.

o Example: "Customer Database" or "Product Inventory."

4. External Entity:
o Represented as a rectangle.

o Represents external users, systems, or organizations interacting with

the system.
o Example: "Customer" or "Payment Gateway."

Example of DFD:
This DFD represents a hotel booking system, showing how customer data
flows through the process of booking a room.

3. Entity Relationship Diagram (ERD)

An ERD is used to represent the data structure of a system, focusing on
how entities relate to each other in a database. ERDs illustrate the entities
involved, their attributes, and the relationships between them, making them
essential for database design.
Common ERD Symbols:
1. Entity:
o Represented as a rectangle.

o Represents an object or concept that stores data.

o Example: "Customer," "Order," "Product."

2. Attribute:
o Represented as an oval connected to an entity.

o Describes a characteristic of an entity.

o Example: "Customer Name," "Order Date."

3. Relationship:
o Represented as a diamond.

o Shows the association between two entities.

o Example: A "Customer" can "Place" an "Order."

4. Primary Key (PK):

o An attribute that uniquely identifies an entity, usually underlined in the
entity box.
o Example: "CustomerID" for the Customer entity.

5. Foreign Key (FK):

o An attribute that links one entity to another.

o Example: "CustomerID" in the "Order" entity, linking it to the

"Customer" entity.
Example of ERD:
This ERD shows a simple relationship between Customers, Orders, and
Products in an e-commerce system.

Comparison of Flowchart, DFD, and ERD:

 Summary:
 Flowchart: Best for visualizing the sequence of operations in a process,
focusing on decisions and actions. It uses symbols like rectangles for
processes and diamonds for decision points.
 DFD: Best for representing how data flows through a system, emphasizing
data movement between processes and data stores. It uses symbols like
circles for processes and arrows for data flows.
 ERD: Best for defining the structure of data in a database, focusing on
entities and their relationships. It uses symbols like rectangles for entities and
diamonds for relationships.