PA

GE

ARBA MINCH UNIVERSITY

Faculty of Computing and Software Engineering
Department of Information Technology

Arba Minch Ethiopia

PA
GE
PA
GE

1.Introduction
1.1 E-Commerce Website and Mobile Application.
The platform is designed to provide a seamless and intuitive shopping experience for
customers, while offering robust management tools for administrators.
The platform supports three distinct user types, each with specific privileges and access to
various features:
Visitors
Visitors can browse the platform without requiring an account. They have access to publicly
available content, including the ability to explore product categories, view detailed product
information (such as size, color, and price), and access static content like About Us, Contact,
and other informational pages.
Customers (Registered Users)
Customers, or registered users, can access all the publicly available features and additional
personalized functionalities. By creating an account and logging in, customers can add products
to their shopping cart, complete the checkout process, and make secure payments for their
orders. Registered users can also track their order history and manage personal information,
enhancing their shopping experience.
Admin Users
Admin users have full control over the website’s backend and content management system
(CMS). Admins can manage all aspects of the platform, including adding and updating products,
processing orders, managing customer accounts, and monitoring overall site performance. They
are responsible for maintaining the website’s functionality, security, and overall user
experience.
The goal of this platform is to provide a user-friendly, secure, and scalable e-commerce
solution. It offers a seamless experience for customers to browse and purchase products while
empowering administrators with tools to manage content, inventory, and orders effectively.
This document will detail the system architecture, functionality, and user workflows, as well as
provide technical specifications for developers and administrators involved in the ongoing
maintenance and enhancement of the platform.
PA
GE

2. System Architecture
2.1. High-Level Architecture Diagram
2.1.1 Front-End
(HTML, CSS, JavaScript, React)
Product Pages
User Account Pages (Login, Registration)
Shopping Cart, Checkout
Admin Panel
API Calls to Backend

2.1.2 Back-End
PA
GE

(PHP - Web Server, REST API, Business Logic)

Authentication & Authorization (JWT/OAuth)
Product Management (CRUD Operations)
Order Management (Checkout, Payment)
User Management (CRUD Operations)
Admin APIs (Manage Products, Users, Orders)
Real-Time Updates (WebSockets)
2.1.3 Database (MySQL)
User Table (user details, credentials)
Product Table (product info, stock levels)
Order Table (order details, status)
Cart Table (items added to cart)
Payment Table (payment history, status)
Review Table (product reviews, ratings)

2.1.4 Justification of Architecture

2.1.4.1 Front-End (HTML, CSS, JavaScript, React):
o HTML and CSS will form the core structure and design of the website, ensuring
responsive and user-friendly layouts.
o JavaScript will handle client-side interactivity, such as form validation, dynamic
page content, and managing user actions without page reloads.
o React will be used to build a responsive, component-based UI, improving the
user experience by allowing the website to be dynamic, with faster load times
and a seamless flow between pages.
o Why React?: React is a powerful JavaScript library for building user interfaces,
allowing for faster rendering (using virtual DOM), easy maintenance, and
scalability. It is ideal for creating dynamic and responsive front-end experiences.
2.1.4.2 Back-End (PHP, REST API, Web Server):
o PHP will handle the server-side logic, including interacting with the database,
processing forms, managing user sessions, and controlling how the front end
communicates with the back end via APIs.
PA
GE

o REST API: A RESTful API will serve as the communication layer between the front-
end and back-end. It will allow front-end components (built with React) to send
requests and receive data asynchronously.
o Real-Time Updates: WebSockets will be integrated for real-time notifications
(e.g., order status updates and new product arrivals), enhancing user
engagement and providing instant updates.
o Why PHP?: PHP is widely used in web development, especially for server-side
scripting, and integrates well with MySQL. It’s cost-effective, flexible, and has a
wide range of frameworks (e.g., Laravel) that can help with rapid development.
2.1.4.3 Database (MySQL):
o MySQL will be used as the relational database to store structured data, including
user profiles, product information, orders, and payments.
o Why MySQL?: MySQL is a robust, widely-used relational database system, known
for its stability, speed, and ease of integration with PHP. It supports ACID
(Atomicity, Consistency, Isolation, Durability) transactions, which ensures data
integrity for e-commerce platforms where financial transactions are involved.
Tables
 Users Table: Stores customer login details, personal information, etc.
 Products Table: Stores product details such as names, prices,
descriptions, images, etc.
 Orders Table: Stores order information, including product IDs, quantities,
order status, and transaction details.
 Cart Table: Temporary storage for users' cart items before checkout.
 Payments Table: Stores payment details (order ID, payment method,
status).
 Reviews Table: Stores customer feedback and ratings on products.

Key Features and Justification for Architecture:

● Scalability: The architecture is designed to scale horizontally, where more front-end

instances or back-end services can be added as traffic increases. React's component-
based architecture also facilitates scalability in the UI.
PA
GE

● Security: The back end uses JWT or OAuth for secure authentication and authorization.
Sensitive data such as passwords will be encrypted, and all sensitive communications
between front end and back end will be handled via HTTPS to ensure security.

● Real-Time Data Processing: The use of WebSockets for real-time updates ensures that
users get immediate notifications (e.g., order tracking or product availability) without
reloading the page.

● Responsive Design: React's ability to dynamically render changes allows the front end to
remain fully functional and responsive across different devices and screen sizes.

3.Database Normalization
3.1 Overview of Normalization
Normalization is the process of organizing data in a database to reduce redundancy and
dependency, ensuring the integrity and scalability of the system. By structuring the database
into distinct entities and establishing clear relationships, we improve data consistency,
minimize data anomalies, and enhance performance.
For this e-commerce platform, normalization has been carried out up to the Third Normal Form
(3NF) to ensure data integrity, optimize storage, and prevent data duplication. Below is a
detailed breakdown of the normalization process and the reasoning behind it.
3.1.1 First Normal Form (1NF)
In 1NF, each column in a table contains atomic (indivisible) values, and each record is unique.
Implementation in Our Database
All tables such as site user, product, order line, and others, are designed to ensure that each
attribute contains atomic values.
There are no repeating groups of columns (e.g., no multiple columns for phone numbers or
addresses in a single row). Each piece of information is stored in its own column, and each
record is uniquely identified by its primary key (PK).
Example
In the site_user table, each row contains distinct user information (e.g., email, phone number)
and is uniquely identified by id.
The user_address table handles multiple addresses for each user by using a foreign key
(user_id), ensuring the addresses are stored separately without repeating the user data.
PA
GE

3.1.2 Second Normal Form (2NF)

 In 2NF, all non-key attributes are fully dependent on the primary key (no partial
dependency).
Implementation in Our Database
 The tables are structured such that all non-primary key attributes are functionally
dependent on the whole primary key.
 For example, in the order line table, the order_id and product_item_id together form the
composite primary key. The qty and price attributes are fully dependent on this composite
key.

Example
The order_line table does not store user information or order status. These are separated into
the shop_order and order_status tables to avoid redundancy and partial dependencies.
The shopping_cart table stores the user reference (user_id), while the items are stored in the
shopping_cart_item table, thus ensuring that items and cart details are kept separate.

3.13 Third Normal Form (3NF)

 In 3NF, no transitive dependencies exist, meaning non-key attributes should not depend on
other non-key attributes.
Implementation in Our Database
 The database design ensures that non-key attributes are only dependent on the primary
key, eliminating transitive dependencies.
 For example, the user_address table does not include information about the country’s
name. Instead, the country table stores this information, and the user_address table refers
to the country table via a foreign key (country_id).
 Example The product table stores product details, such as name,description, and
product_image, which are directly related to the product’s id. There are no non-key
attributes dependent on other non-key attributes (e.g., no separate storage for product
categories or variations). Instead, the relationships are handled through product_category
and variation tables.
 The order_status table is separated from the shop_order table, ensuring that changes in
order status (e.g. Pending, Shipped) do not require updating the order record itself.
PA
GE

Entity Relationship Overview

The database schema has been normalized to 3NF while keeping real-world use cases in mind.
The following tables are involved in ensuring data consistency, reducing redundancy, and
optimizing queries for performance:
Users The site_user, user_address, and country tables handle user credentials, their multiple
addresses, and location information, ensuring that all user-related data is efficiently stored and
retrieved.
Products The `product`, `product_item`, `product_category`, `variation`, and `variation_option`
tables store product details and their variations, organized into categories to facilitate easy
retrieval and filtering based on user preferences.
Orders and Payments The `shop_order`, `order_line`, `order_status`, `shopping_cart`, and
`shopping_cart_item` tables handle order details, payment methods, and cart information
while avoiding unnecessary data duplication and ensuring referential integrity through foreign
key relationships.
Promotions The `promotion` and `promotion_category` tables store details of promotional
campaigns and their applicability to product categories.
Key Benefits of Normalization
1, Data Integrity: By organizing the database into smaller, logically structured tables, we reduce
the risk of data anomalies such as update, insert, or delete anomalies.
2. Storage Efficiency: The design ensures minimal redundancy by eliminating repeating groups
and non-essential attributes from main tables, thus optimizing storage space.
3. Scalability and Maintenance: The normalized design makes it easier to scale the system as
more products, users, and orders are added. New features or changes to the system can be
implemented without disrupting the entire database structure.
4. Query Optimization: The normalized structure facilitates the creation of optimized SQL
queries, as data is stored in smaller, more manageable tables with clear relationships,
improving query performance over time.
PA
GE

4.Object-Oriented Programming (OOP) Design Patterns

 Patterns and how they apply to your e-commerce platform. I'll also provide code snippets in
Java to demonstrate how these patterns can enhance maintainability, scalability, and the
overall structure of the application.
4.1 OOP Design Patterns for E-commerce Platform
4.1.1Overview of OOP Design Patterns
 OOP Design Patterns are reusable solutions to common problems that occur during
software development. These patterns help in organizing and structuring code in a way that
improves maintainability, scalability, and flexibility.
For your e-commerce platform, we’ll use three common Design Patterns
1. Singleton
2. Factory
3. Observer
 Each of these patterns addresses different aspects of the system, helping make the
codebase more robust and manageable.
4.1.2 Singleton Design Pattern
What is the Singleton Pattern?
 The Singleton pattern ensures that a class has only one instance throughout the entire
application and provides a global point of access to that instance.
 In the context of an e-commerce system, there are scenarios where you need to ensure that
certain services (like the Database Connection or Configuration Manager) are accessed via a
single instance to avoid redundancy and maintain consistency.
 Example Use Case for E-commerce Database Connection Manager You would only want
one instance of the database connection throughout the application to prevent multiple
connections from opening.
PA
GE

Java Code Example

Explanation
getInstance() method ensures that only one instance of DatabaseConnection is created, even if
multiple requests are made for a connection.
 This prevents creating multiple database connections and ensures that your system is
efficient and consistent.
 Benefits for E-commerce
 Ensures there is only one database connection throughout the application.
 Avoid issues like having multiple configurations in different parts of the system.
4.1.3 Factory Design Pattern
What is the Factory Pattern?
 The Factory pattern is used to create objects without specifying the exact class of object that will
be created Instead, a factory method is used to instantiate objects, allowing the system to
decide which class to instantiate based on specific conditions.
 In an e-commerce system, this pattern is useful for creating different types of payment
processors or product variations without hard-coding the logic.

 Example Use Case for E-commerce

PA
GE

o Payment Method Factory: When a user selects a payment method (Credit Card, PayPal,
etc.), the system should dynamically instantiate the correct payment processor without
needing to know the specifics.

Java Code Example

Explanation:
 PaymentProcessorFactory is responsible for deciding which type of payment processor to
create based on the payment type (CreditCard, PayPal).
 This way, the system can easily extend to add more payment methods by simply adding
new classes without changing existing code.

Benefits for E-commerce

PA
GE

 Flexibility Easily add new payment methods without changing the core payment
processing logic.
 Maintainability Centralizes the creation logic in one place, so it’s easier to manage and
scale.
4.1.4 Observer Design Pattern
What is the Observer Pattern?
 The Observer pattern is used when one object (the subject) needs to notify other objects
(the observers) when a state change occurs. It’s commonly used in scenarios where multiple
components need to react to changes in state or data.
 In an e-commerce platform, the Observer pattern can be used for real-time updates, such as
updating the user's order status or sending notifications about new product arrivals.
 Example Use Case for E-commerce Order Status Update: Once an order is shipped, various
observers (such as the user’s account, the admin panel, and inventory) need to be notified
about the status change.

Java Code Example

PA
GE
PA
GE

Explanation
 The Order class acts as the subject and maintains a list of observers.
 When the order status changes (e.g., from Pending to Shipped) all registered observers
are notified via the update() method.
 This allows multiple components (e.g. user notifications and admin updates) to react to
the change in status without tightly coupling them to the order logic.
 Benefits for E-commerce:
 Real-Time Notifications Allows the system to easily notify different parts of the platform
(users and admins) when something important happens (like an order status change).
 Loose Coupling: The observer and the subject are loosely coupled, meaning you can add
or remove observers without affecting the core system.

Conclusion
By using these OOP design patterns Singleton, Factory, and Observer your e-commerce
system becomes
 Scalable You can easily add new features or modify existing ones without affecting
other parts of the system.
 Maintainable The code is structured in a way that makes it easy to maintain and debug.
 Extensible New functionality (like adding new payment methods or real-time updates)
can be added with minimal changes to the existing codebase.
5.Project Management Strategy
In this section, we will define the project management approach for developing the e-
commerce platform. The strategy will focus on utilizing Agile methodologies to ensure
flexibility, iterative progress, and effective collaboration across teams. This approach allows us
to adapt to changes, manage the project in smaller manageable chunks, and ensure regular
delivery of working features.
5.1 Agile Methodology Overview
5.1.2Agile
 Agile is an iterative project management framework that emphasizes continuous delivery,
flexibility, and team collaboration. It is particularly useful for projects where requirements
can evolve, and there is a need for rapid development and testing.
 The development process is broken down into sprints, each of which produces a potentially
shippable product increment.
5.1.3Phases of the Project
PA
GE

 The development will be divided into several phases based on the Agile framework, with
each sprint focusing on a specific set of deliverables. Below is a breakdown of the project
phases.
Phase 1: Initial Planning and Requirements Gathering
o Objectives Understand business requirements, define product features, and gather
feedback from stakeholders.
o Duration 1-2 weeks

Activities
 Meetings with stakeholders to clarify business needs.
 Define user stories for the e-commerce platform.
 Prioritize features and map out a product roadmap.
Phase 2 Sprint 1 – Core Features (Backend and Frontend Integration)
o Objectives Develop and integrate core features such as user authentication, product catalog,
and basic shopping cart functionality.
o Duration 2-3 weeks

Activities
 Set up backend architecture, database schema, and user authentication system.
 Frontend development of basic pages (home, product catalog, login/registration).
 Initial testing of user authentication and product display.
Phase 3 Sprint 2 – Order Management & Payment Gateway
o Objectives Develop the order management system and integrate a payment gateway.
o Duration 2-3 weeks

Activities
 Implement order placement, cart management, and checkout features.
 Integrate payment processors (e.g., PayPal, Stripe).
 Test order processing and payment functionality.

Phase 4 Sprint 3 – User Profile and Admin Dashboard

o Objectives Develop features for managing user profiles, admin dashboard for order
management, and promotional features.
o Duration 2-3 weeks

Activities
PA
GE

 User profile management (order history, preferences).

 Admin features for managing products, orders, and users.
 Testing admin panel and ensuring system security.

Phase 5 Sprint 4 – Mobile Application Developmen

o Objectives Develop the mobile application version of the e-commerce platform.
o Duration 3-4 weeks

Activities
 Develop mobile applications (iOS and Android) with the same core features.
 Focus on responsive design for the app to ensure a smooth user experience.
 Integration with the backend and testing on real devices.
Phase 6 Sprint 5 – Final Testing, Debugging, and Deployment
o Objectives Complete final testing and deploy the platform.
o Duration 2 weeks

Activities
 Perform end-to-end testing (unit tests, integration tests, user acceptance tests).
 Debug and fix any remaining issues.
 Deploy the platform to production and ensure everything works as expected.
5.2 Sprint Planning and Iterations
Each Sprint (typically 2-3 weeks long) will include the following key components.
Sprint Planning At the start of each sprint, the team will meet to discuss the goals for the
sprint, which features to develop, and how to divide the work among team members.
Daily Stand-ups Short daily meetings to discuss progress, blockers, and next steps. This
helps ensure the team stays on track and can adapt quickly to any changes.
Sprint Review and Retrospective At the end of each sprint, a review meeting will be held to
demonstrate the completed features to stakeholders. The retrospective allows the team to
discuss what went well, what could be improved, and how to adjust processes for the next
sprint.
Team Roles and Responsibilities
The following team roles will be defined for the project
Project Manager (PM) Responsible for overall project planning, tracking progress, and
ensuring deadlines are met. Acts as the main point of contact for stakeholders and ensures
that feedback is incorporated into the development process.
Lead Developer Leads the development team and ensures the technical aspects of the
platform are on track.
PA
GE

 Responsible for code quality, architecture decisions, and setting up the development
environment.
Frontend Developer
Responsible for developing the user interface (UI) and ensuring a responsive design that works
across different devices (web and mobile).
Backend Developer
Handles the server-side development, APIs, and database design.
Ensures data integrity, security, and performance optimization for the platform.
Quality Assurance (QA)
Conducts thorough testing at each stage to ensure the platform is bug-free and functions as
expected.
Runs unit tests, integration tests, and user acceptance tests.
UX/UI Designer
Designs the user interface (UI) and user experience (UX) to ensure the platform is intuitive
and easy to navigate.
Focuses on both the website and mobile application design for consistency and usability.
Security Expert
Responsible for ensuring the platform adheres to security best practices (e.g., data encryption,
secure payment processing).
Implements authentication and authorization systems.
5.3 Timeline for the First Three Sprints

Sprint Duration Goals / Deliverables Responsible Teams

Sprint1 2-3 Weeks - User authentication system Backend, Frontend
- Product catalog page
- Basic shopping cart
functionality
Sprint2 2-3 Weeks - Order management system Backend, Frontend, QA
- Payment gateway integration
- Basic checkout process
Sprint3 2-3 Weeks - User profiles Backend, Frontend, Admin
- Admin dashboard
- Order management for
admins
PA
GE

5.3.1 Communication and Reporting

Weekly Progress Reports The team will provide weekly updates to stakeholders, including
progress, challenges, and upcoming tasks.
Project Management Tools We will use tools like JIRA or Trello for task tracking, sprint
planning, and issue management.
Regular Demos At the end of each sprint, we will hold a demo session to showcase the
progress and get feedback from stakeholders.
5.3.2 Risk Management and Mitigation
 Risk Delays in the mobile app development phase due to platform differences.
 Mitigation Start mobile development early and allocate resources for cross-platform
development.
 Risk Integration challenges with payment gateways.
 Mitigation Conduct early testing with multiple payment providers and allocate time for
troubleshooting.
6.Security Framework
 The security of the e-commerce platform is critical to protect sensitive customer data,
ensure secure transactions, and comply with regulatory standards. This framework will
outline the multi-layered security approach for safeguarding the platform across
authentication, data protection, and network security.
6.1 Authentication and Authorization
 Goal Ensure only authorized users can access the system, with appropriate permissions for
different user roles.
 Role-based Access Control (RBAC) Implement user roles (e.g., Admin, Customer) to restrict
access to specific resources based on user type.
 Two-Factor Authentication (2FA) Enhance security by requiring an additional verification
step (e.g., OTP or email confirmation) for sensitive actions like login and payment.
 OAuth 2.0 Use OAuth for secure authentication, allowing users to log in via third-party
providers (e.g. Google, Facebook) without sharing passwords.
 JWT (JSON Web Tokens) Implement JWT for managing session tokens and ensuring secure
communication between front-end and back-end services.
6.2 Data Protection and Encryption
 Goal Protect sensitive user data such as passwords, payment information, and transaction
details.
 Measures
PA
GE

 Data Encryption Encrypt all sensitive data both in transit and at rest using strong encryption
standards (e.g., AES-256 for data at rest, TLS 1.2 or higher for data in transit).
 Password Hashing Store user passwords securely using strong hashing algorithms like bcrypt
or Argon2 This ensures that even if a database is compromised, user passwords are not
exposed.
 PCI-DSS Compliance Ensure that payment information is handled in compliance with the
Payment Card Industry Data Security Standard (PCI-DSS) This includes encrypting credit card
numbers and securely storing only minimal information (e.g., not storing full card numbers).
 Data Masking Mask sensitive information (e.g., credit card numbers, bank account details)
in user-facing interfaces or logs.
6.3 Network Security
 Goal Ensure that the platform remains secure against external threats and that user data is
protected during interaction with the system.
 Firewalls Use Web Application Firewalls (WAF) to filter and monitor HTTP traffic, protecting
the platform from common attack vectors (e.g., SQL injection and cross-site scripting).
 Intrusion Detection and Prevention Systems (IDPS) Implement monitoring systems that can
detect and respond to unusual network activity or potential intrusions.
 DDoS Protection Utilize DDoS protection services (e.g., Cloudflare, AWS Shield) to mitigate
Distributed Denial of Service attacks and ensure the platform remains available under high
traffic conditions.
 Load Balancers Distribute network traffic evenly across multiple servers to prevent any
single server from being overwhelmed while enhancing availability and fault tolerance.
 Secure Payment Gateway Integration Goal Safeguard payment transactions and protect
sensitive financial data.
 Payment Tokenization Use tokenization to replace sensitive payment information (e.g.,
credit card numbers) with non-sensitive tokens, reducing the risk of exposure.
 3D Secure Authentication Implement 3D Secure (e.g., Visa Secure, Mastercard Identity
Check) to add an additional authentication layer during online payments.
 SSL/TLS Encryption Use SSL/TLS certificates to ensure that all payment data transmitted
between the client and server is encrypted and secure.
6.4 Secure Software Development Practices
 Goal Ensure the platform is developed with security best practices in mind from the start.
 Measures
 Secure Coding Standards Follow secure coding practices to avoid common vulnerabilities
such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
 Code Reviews and Static Analysis Conduct regular code reviews and use static code
analysis tools (e.g., SonarQube) to detect potential security flaws during the development
process.
PA
GE

 Vulnerability Scanning Regularly scan the platform for vulnerabilities using automated
tools (e.g., OWASP ZAP, Nessus) and address identified risks promptly.
6.6 Security Monitoring and Logging
 Goal Continuously monitor the platform for potential security incidents and maintain an
audit trail of system activities.
 Centralized Logging Use centralized logging (e.g., with tools like ELK Stack or Splunk) to
record all user activity, transactions, and system events.
 Real-time Monitoring Implement real-time monitoring to detect abnormal system
behavior, potential breaches, or unauthorized access attempts.
 Audit Trails Ensure that detailed logs are maintained for critical activities, such as user
login/logout, payment processing, and admin actions, for security audits and investigations.
6.6 Compliance with Regulatory Standards
 Goal Ensure that the platform complies with relevant data protection and security
regulations.
 GDPR Compliance Implement measures to comply with the General Data Protection
Regulation (GDPR), ensuring proper handling of customer data, including consent
management, data access, and the right to be forgotten.
 CCPA Compliance Ensure compliance with the California Consumer Privacy Act (CCPA),
providing users with rights over their personal data and ensuring transparency in how data
is handled.
 ISO/IEC 27001 Ensure that the platform follows the ISO/IEC 27001 standard for information
security management, including the establishment of a robust information security
management system (ISMS).
Diagram Security Architecture
Below is a high-level security architecture diagram illustrating the integration of security layers
within the system:

Client Side (Web/Mobile)

HTTPS (TLS/SSL)
Authentication (JWT, 2FA)
Payment Tokenization (PCI-DSS)
PA
GE

Application Layer (Backend)

Web Application Firewall (WAF)
Secure APIs (OAuth 2.0)
Role-Based Access Control (RBAC)
Database Encryption (AES-256)

Database and Network Layer

Intrusion Detection & Prevention (IDPS)
Load Balancers, Redundant Servers
Firewalls and DDoS Protection
Encryption of Data at Rest (AES-256)

7.Network Configuration and Failover

A critical aspect of building a reliable and highly available e-commerce platform is ensuring that
the network infrastructure is robust, scalable, and capable of handling unexpected disruptions
or failures. This section outlines the design for network topology, load balancing, and failover
mechanisms to minimize downtime and enhance system availability.
7.1 Network Topology
The network topology for the e-commerce platform will be designed to ensure high availability,
redundancy, and scalability. The architecture includes multiple layers, such as front-end web
servers, back-end application servers, and database clusters, each protected by load balancers
and security layers.

7.1.2 High-Level Network Topology

Internet

Load Balancer <-- Distributes traffic to web servers.

PA
GE

Web Server 1

Database Server <-- MySQL DB for storage

External APIs <-- Third-party API services

7.2 Load Balancing

 Goal Distribute network traffic evenly across multiple servers to ensure no single server is
overloaded, improving performance and availability.
7.2.1 Load Balancers
 We will use Layer 4 (TCP) and Layer 7 (HTTP) load balancers to distribute traffic between
the front-end web servers and application servers.
 Popular load balancing solutions like Nginx, HAProxy, or AWS Elastic Load Balancer (ELB)
will be used.
 The load balancers will monitor the health of the web servers and redirect traffic away from
any server that becomes unavailable.
 Round-robin Load Balancing This method will distribute client requests sequentially to each
server in the pool, ensuring that the load is balanced evenly.
 Sticky Sessions For certain user sessions (e.g., shopping carts or user login), sticky sessions
will be used to maintain stateful connections with specific backend servers.
 Redundancy and Failover
 Goal Ensure that the platform remains operational even in the event of server or
component failure, providing seamless recovery with minimal downtime.
7.2.2 Web Servers
 Deploy at least two web servers (in different availability zones or data centers) to handle
incoming traffic. This ensures that if one server fails, the other can continue handling
requests.
7.2.3 Application Servers
 Similarly, there will be at least two application servers for backend processing. These
servers will be connected to the load balancer and will operate in an active-active or active-
passive mode.
 In case of failure, the load balancer will route traffic to the healthy application server.
PA
GE

7.2.4 Database Cluster and Failover The database layer will consist of a primary database
server and secondary/replica databases. In the event of a primary database failure, the
system will automatically promote a secondary database to the primary to maintain data
availability.
MySQL Replication or MariaDB Galera Cluster can be used for this setup, enabling real-time
data replication between the primary and replica databases.
Database Backup Regular backups will be taken to ensure that data can be recovered in
case of catastrophic failures.
 These backups will be stored in a secure offsite location or in cloud storage.
Failover Process Automatic failover processes will be set up for both web and application
servers. If any component (server, database) fails, the system will immediately route traffic
to the backup server or database without user disruption.
DNS failover can also be used to automatically update DNS records if one data center goes
down, ensuring users are routed to a working server.
7.2.5 Network Resilience Goal Ensure the platform can withstand network issues such as high
traffic spikes, DDoS attacks, or hardware failures.
Redundant Network Paths Use multiple network paths (from different ISPs) to connect
servers to ensure that if one path fails, traffic is rerouted through another.
 This minimizes the risk of downtime due to network outages.
DDoS Protection Utilize DDoS protection services such as Cloudflare, AWS Shield, or Google
Cloud Armor to mitigate large-scale attacks and prevent the platform from being
overwhelmed by malicious traffic.
Auto-Scaling The system will be configured to auto-scale based on demand. During periods
of high traffic (e.g., sales events), the platform will automatically spin up additional
web/application servers to handle the load.
High Availability Setup Goal Ensure that the platform remains available 24/7 with minimal
downtime, even in the event of system failures or maintenance.
Multi-Region/Availability Zone Deployment The platform will be deployed in multiple
regions or availability zones (if using cloud infrastructure like AWS, Azure, or GCP).
 This geographic redundancy ensures that if one data center or region goes down, another
can take over without disruption.
Hot and Warm Standby Servers
 For mission-critical components like databases, application servers, and load balancers, we
will maintain hot standby servers that can take over immediately if the primary server fails.
 For less critical components, warm standby can be used, where servers are kept up-to-date
and can be activated if needed.
7.3 Diagram Network Configuration and Failover
Below is a simplified diagram of the proposed network failover and redundancy architecture.
PA
GE

Users
(Web/Mobile)

Load Balancer

Web Server 1 Web Server 2

App Server 1 App Server 2

Database Server Database Server

Backup Database Backup Database

8.Mobile Application Development

 As part of providing a seamless user experience across platforms, the e-commerce system
will have a mobile application version. This application will allow users to browse products,
manage their shopping carts, make purchases, and track orders, all from their smartphones.
The mobile app will be developed to ensure optimal usability, fast performance, and
responsive design.
8.1 Mobile App Strategy
 The goal of the mobile app development is to provide a fully functional, user-friendly, and
secure interface for users while integrating seamlessly with the backend of the e-commerce
platform.
8.1.1 Key Features of the Mobile Application
PA
GE

Product Browsing Users can browse products by category, view product details, and filter
products based on size, color, and price.
Shopping Cart Users can add products to the shopping cart, view their cart items, and
modify quantities.
Secure Checkout The app allows users to checkout securely using various payment methods
(credit cards, PayPal, etc.), with an option to save payment information.
Order Tracking Users can track the status of their orders in real-time.
User Account Management Users can create, update, and manage their accounts,
addresses, and payment methods.
Push Notifications The app will send push notifications to users about order updates,
promotions, or cart reminders.
Ratings and Reviews Users can leave ratings and reviews on products they purchase.
8.2 Mobile Application Architecture
The architecture of the mobile application will consist of two main components: the front-end
(mobile app) and the back-end (server-side APIs). The mobile app will communicate with the
backend to retrieve product information, process transactions, and handle user authentication.
8.2.1 Mobile Application Components
1, Front-End (Mobile App) Developed using React Native (or native development tools like
Swift for iOS and Kotlin for Android) to create a cross-platform app that works on both Android
and iOS devices.
2, Backend The mobile app will interact with the backend APIs developed using PHP and
MySQL to fetch data, manage sessions, and handle transactions.
3, Database The database for the mobile app will sync with the same MySQL database used for
the e-commerce website to ensure consistency across platforms.
8.2.2 Mobile App Architecture Diagram

Mobile App (iOS/Android) Backend API

User Interface PHP RESTful APIs
Product Listing Authentication
Cart Management Order Processing
Push Notifications Payment Integration
User Account
PA
GE

MySQL Database
Push Notification Products
Service (e.g., Firebase Orders Users
Cloud Messaging) Data, etc

8.3 Responsive Design Principles

The mobile app will be designed with responsive design principles in mind to ensure that the
application is usable across various devices with different screen sizes, resolutions, and
orientations.
8.3.1 Responsive Design Features
Flexible Layouts The app will use flexible layouts that adapt to different screen sizes and
resolutions. This ensures that the app works well on both smartphones and tablets.
Adaptive UI Elements UI elements, such as buttons and images, will be dynamically
adjusted based on screen size to ensure ease of use.
Cross-Platform Consistency The mobile app will provide a consistent user experience across
both iOS and Android platforms, with minimal differences in functionality and design.
8.3.2 Design Tools
React Native Allows for the creation of a cross-platform application, ensuring that the
mobile app functions seamlessly on both iOS and Android without the need for separate
codebases.
Material Design For Android, the app will follow Google’s Material Design principles for a
familiar and intuitive user interface. For iOS, the app will follow Apple’s Human Interface
Guidelines.
User Experience (UX) and User Interface (UI) Design
The mobile app will focus on delivering an intuitive and smooth user experience (UX). The app
will be designed to be fast, responsive, and easy to navigate. Key considerations for the UX/UI
design include:
Intuitive Navigation The app will have easy-to-access navigation menus for browsing products,
accessing the shopping cart, managing the user account, and viewing order history.
PA
GE

Quick Load Times The app will be optimized for performance, ensuring fast load times even
on slower networks.
Minimalist Design The UI will follow a minimalist approach, providing essential information
clearly and avoiding unnecessary clutter.
Easy Checkout Process The checkout process will be streamlined with clear instructions,
easy input forms, and multiple payment options to ensure users can complete their
purchases quickly and securely.
8.3.3 Data Communication and Efficiency
Data efficiency and communication between the mobile app and the backend are key factors in
ensuring a smooth user experience. Here are the strategies to achieve this:
API Optimization The backend APIs will be optimized to handle mobile-specific requests
efficiently, reducing data transfer times and ensuring quick response times. The mobile app
will interact with the backend using RESTful APIs.
Data Caching To reduce data load times, the mobile app will cache product data, user
preferences, and cart information locally on the device, allowing users to continue browsing
even when network connectivity is slow or intermittent.
Push Notifications The app will use push notifications to keep users engaged, sending real-
time updates on order status, special offers, and abandoned cart reminders.
8.4 Mobile App Security
Security is a key concern for any mobile application, especially one handling sensitive customer
information such as personal data and payment details. The mobile app will incorporate the
following security measures:
Data Encryption All sensitive data exchanged between the app and the backend (including
payment information) will be encrypted using industry-standard encryption protocols (e.g.,
TLS/SSL).
Secure Authentication The app will support secure user authentication mechanisms, such
as OAuth 2.0 for login and Two-Factor Authentication (2FA) for sensitive operations like
payments and account changes.
Token-based Authentication (JWT) The mobile app will use JSON Web Tokens (JWT) for
user session management, allowing the app to securely authenticate users without
repeatedly asking for login credentials.
Local Storage Security Sensitive information stored locally (e.g., payment details and user
preferences) will be encrypted using strong encryption techniques to prevent unauthorized
access.
8.4.1 Mobile App Development Tools
React Native Chosen for cross-platform development, React Native allows the development
of both Android and iOS apps using a single codebase.
PA
GE

Firebase Cloud Messaging (FCM) For handling push notifications and messaging across
platforms.
Redux To manage the state of the application and ensure consistency between different
views and components.
Axios For making HTTP requests from the mobile app to the backend APIs.