Page |1

Research and Analysis

Research
Architecture in Monoliths:
An application is built, deployed, and managed as a single unit in a monolithic architecture. The
user interface, business logic, and data access layer are examples of closely interconnected
components.
The ability to scale It is possible to grow monolithic designs vertically by increasing the server's
hardware resources, which is where the application is located. However, because of the close
interdependence of components, horizontal scaling—that is, adding more servers—can be
difficult. It can be inefficient to run numerous instances of the entire application when using
horizontal scaling.

Suitability: Smaller applications with steady user populations and predictable traffic are typically
better suited for monolithic systems.

Architecture of Microservices:
An application can be divided into smaller, independent services, each handling a single task,
using the microservices design. Through APIs, these services can interact with one another.
Scalability considerations: Microservices provide the autonomous scalability of every service
according to its unique needs. This makes it possible to use resources more effectively than with
monolithic designs. High demand services can be horizontally scaled without compromising
other services.

Suitability: Large, complex applications with a wide range of functionalities and varied
scalability needs are a good fit for microservices architectures. They encourage fault separation,
scalability, and agility.

Architecture of Serverless:
The cloud provider dynamically controls the provisioning and allocation of servers in a
serverless architecture. Developers don't bother about server maintenance; instead, they
concentrate on writing code.
The ability to scale Take into account that serverless systems adjust automatically to demand.
They are able to efficiently manage abrupt increases in traffic since the cloud provider
transparently manages resources. However, the restrictions put in place by the cloud provider can
prevent scaling.

Suitability: Applications that are extremely scalable, event-driven, and have erratic traffic
 Page |2

patterns can benefit from serverless architectures. They may be reasonably priced, particularly
for applications with irregular use.

Alternative Designs:
Containerized Architectures applications can be packaged and deployed in a lightweight and
portable manner with the help of containerization, which makes use of technologies like Docker
and Kubernetes. Containers provide flexibility in managing dependencies and resources and
allow for horizontal scaling.

Hybrid architectures combine aspects of several systems—such as serverless and microservices

—to satisfy particular needs. For instance, managing asynchronous tasks in a microservices-
based application with serverless functions.

Analysis
The best option for a Customer Information Management web application will be Microservices
Architecture, it is decided after a thorough analysis of various software architectures. This is
because it can manage traffic with various aspects of Customer Management such as registration,
billing, request for services, making complain etc. The service will function without difficulty
during periods of high customer traffic and won't interfere with other services.

Needs for Scalability

In light of the scalability specifications for the web application I suggested, we must evaluate
elements like:

An anticipated 35 million users

The rate of traffic is 30,000 users per minute.
Data volume: 5 TB, and we will require an additional 5 TB in the next decades.
Forecasted future growth: 5% yearly growth.
 Page |3

Architecture Design

Modules
1. User Service:
Responsibilities:

 Handles user registration and authentication.

 Manages user profiles and permissions.
Interactions:

 Communicates with other services for user-related operations.

2. Billing Service:
Responsibilities:

 Manages billing information, including payment methods and invoices.

 Processes payments and generates invoices.
Interactions:

 Integrates with external payment gateways.

 Communicates with the User Service for user information.
3. Service Request Service:

Responsibilities:

 Handles customer requests for services.

 Manages service availability and scheduling.
Interactions:

 Communicates with the User Service for authentication.

 Integrates with external service providers if necessary.
 Page |4

4. Complaint Management Service:

Responsibilities:

 Manages customer complaints and feedback.

 Tracks the status and resolution of complaints.
Interactions:

 Communicates with the User Service for authentication.

 May integrate with external ticketing or CRM systems.

Architectural Considerations
Load Balancing
 Use a load balancer to distribute incoming requests among microservices
instances.
 Implement auto-scaling to adjust the number of instances based on
demand.

Caching Mechanisms
 Employ caching for frequently accessed data to improve performance.
 Each microservice can have its own caching layer for data it frequently
accesses.

Data Storage
 Use separate databases for each microservice to ensure loose coupling.
 Choose databases based on the specific needs of each service.
For example:
 User Service: SQL or NoSQL database for user profiles.
 Billing Service: Database optimized for financial transaction
 Complaint Management Service: Database for storing complaint
details.
 Page |5

Communication Between Components:

 Use asynchronous messaging for inter-service communication to
decouple services and handle high loads.
 Implement message queues or event-driven architectures for reliable
communication.

Interaction Flow
1. User Registration and Authentication:
 User sends registration/authentication requests to the User Service.
 User Service verifies credentials and creates/returns authentication
tokens.
2. Billing Operations:
 User or other services send billing requests to the Billing Service.
 Billing Service processes payments or generates invoices and updates
the billing information.
3. Service Requests:
 Users submit service requests through the Service Request Service.
 Service Request Service schedules the requested services and updates
the status.
4. Complaint Management:
 Users submit complaints through the Complaint Management Service.
 Complaint Management Service tracks the complaints, assigns them
for resolution, and updates their status.
 Page |6

Technology Selection

For creating the customer management used

technology are listed below:
Programming Language:

Python is one of the most often used languages for creating microservices because of its
readability and simplicity. Java is a great language to choose if you want performance and
scalability at the same time. The construction of this architecture will be done using these two
programming languages.

Frameworks:

Django is a Python framework that is perfect for constructing architecture since it is incredibly
lightweight and adaptable. It also offers simple-to-use APIs.

Databases:
MySQL is the greatest option for storing all the important data, including user and product
details, because of its dependability and systematic sorting.

Cloud Services:

Amazon Web Service (AWS) and Google Cloud Platform (GCP) are highly well-liked for
serverless computing and for offering scalability and dependability among a variety of cloud
services.

By choosing these technologies, a scalable, dependable, and performance-satisfying architecture

will be constructed.
 Page |7

Documentation

Creating UML diagram and Use case diagram for the

system
UML Diagram

Provider
-Username
-Password
Manage users()
Login/logout()
Update_profile()

Line man Line man

-Username -Username
-Password -Password
-Title +Full Name
Login/logout() +Meter Number
Update_profile() +Contact Number
Accept Complaint() +Identification Number
Delivery services() Login/logout()
Update_profile()
Make Complaint()
Request services()
Pay Bills()

Cashier
-Username
-Password
+Title
Login/logout()
Update_profile()
Send Bills()
Accept Bills()
 Page |8

Use Case Diagram

Manage users

Login/log out
Provider

Update Profile

Accept Make
Complaint Complaint
Line Man
Request services Consumer

Delivery services

Cashier Accept
Bill Pay Bill
Apply for
Send Bill meter

Summarize Documentation:
The module consists of four modules: User Service, Billing Service, Service Request Service, and
Complaint Management Service. Each module handles user registration, authentication, billing
operations, service requests, and complaints. The architecture considers load balancing,
caching mechanisms, data storage, and communication between components. The User Service
 Page |9

handles user registration and authentication, while the Billing Service processes payments and
generates invoices. The Service Request Service handles customer requests for services,
manages service availability and scheduling, and may integrate with external systems. The
Complaint Management Service manages customer complaints and feedback, and may
integrate with external systems. The module also includes asynchronous messaging for inter-
service communication and message queues or event-driven architectures for reliable
communication.

Reference:
Scalable Architecture: A Definition and How-To Guide:
https://www.sentinelone.com/blog/scalable-architecture/

How to design software architecture: Top tips and best practices:

https://www.lucidchart.com/blog/how-to-design-software-architecture

The definitive guide to building a scalable software:

https://medium.com/geekculture/the-definitive-guide-to-building-a-
scalablesoftware-f93235f410

Microservices Pattern: API Gateway:

https://microservices.io/patterns/apigateway.html