╔═══╗╔═══╗╔═══╗╔╗ ╔╗ ╔═══╗╔═══╗╔═══╗╔═══╗
║╔══╝║╔═╗║║╔═╗║║╚╗╔╝║ ║╔═╗║║╔═╗║║╔═╗║║╔═╗║
║╚══╗║║ ║║║╚══╗╚╗╚╝╔╝ ║╚═╝║║║ ║║║╚══╗║╚══╗
║╔══╝║╚═╝║╚══╗║ ╚╗╔╝ ║╔══╝║╚═╝║╚══╗║╚══╗║
║╚══╗║╔═╗║║╚═╝║ ║║ ║║ ║╔═╗║║╚═╝║║╚═╝║
╚═══╝╚╝ ╚╝╚═══╝ ╚╝ ╚╝ ╚╝ ╚╝╚═══╝╚═══╝
The EasyPass" distributed E-ticketing system is a platform made to make managing and selling event tickets easier. It consists of several microservices, each in charge of certain functions including order processing, user authentication, and event catalogue maintenance. The system guarantees security, scalability, and dependability while enabling users to peruse, buy, and manage tickets for a range of occasions.
In real-world scenarios, websites often experience downtime during events due to high traffic. Easy Psss was designed to tackle this issue by utilizing distributed computing techniques to enhance service reliability. The system consists of distributed, scalable components as a frontend, API gateway, and backend microservices across three node tiers. For the implementation, kubernetes was used as the container orchestration service. Evaluation of effectiveness involved comparing performance metrics for different scenarios and analyzing numerical data from test cases in later stages.
Group Details:
- Kavindu Wijesinghe - Kavindu.WijesingheArachchilage@student.oulu.fi
- Nirasha Thennakoon - Nirasha.KaluarachchiThennakoonAppuhamilage@student.oulu.fi
- Sonali Prasadika - Sonali.LiyanaBadalge@student.oulu.fi
- Iresh Jayasundara - Iresh.JayasundaraMudiyanselage@student.oulu.fi
figure : High Level System Architecture
- User and DNS resolver- These entities will act external to the system
-
Load balancer - Direct the HTTPS request to frontend instances considering the current traffic.
-
Instances - Frontend instances will be the customer face and has the ability to scale up or down with the incoming traffic
-
API Gateway - Central point of the API endpoints and will handle the initial required authentication, conversions and gateway level logic
-
Authentication Microservice - Ensures secure access to the platform by verifying user identities and authorizing access to protected resources, safeguarding user data and system integrity. Functionalities include user authentication and authorization, password management, and session management
-
Event Catalog Microservice - Facilitates event discovery for users, driving engagement and ticket sales by offering a comprehensive view of available events. Functionalities include managing catalog of events, providing information on upcoming events, schedules, and venue details.
-
Ticketing Microservice - Handles the ticket management, ensuring efficient allocation and sale of tickets. Functionalities include managing ticket inventory, availability, reservations, and sales.
-
Payment Microservice - Ensures secure and reliable payment transactions, Handles payment processing, including gateway integration, and error handling.
-
Order Management Microservice - Facilitates smooth and efficient order processing, Manages order lifecycle, including creation, modification, cancellation, and fulfillment.
- Database - Repository for storing and managing critical data related to users, events, tickets, orders, payments, and other essential information.
Figure : Simplyfied event flow
Misco Services has been used to implement the project following the Service Oriented Architecture. The microservice architecture enables an organization to deliver large, complex applications rapidly, frequently, reliably, and sustainably. More details about the microservices can be found here.
Based on the microservice architecture, Distributed-E-Ticketing Easy Pass system implements five main services: user service, ticketing service, event service, order management service, and payment service.
- User-service - managing user related functionalities
- Ticketing service - managing ticket reservation, availability etc
- Event service - handle event related functionalities
- Order management service - manage orders
- Pyament service - handle payement requests like purchases, refunds
The Easy Pass defines several API endpoints using HTTP methods such as POST, GET, PUT, and DELETE. For example:
- /api/event (POST): Creates a new event.
- /api/events (GET): Retrieves all events.
- /api/event/:id (GET): Retrieves a specific event by its ID.
- /api/event/:id (PUT): Updates a specific event by its ID.
- /api/event/:id (DELETE): Deletes a specific event by its ID.
These endpoints function as communication channels through which clients can communicate with the server to perform CRUD operations on events. The communication between services is handled using Representation State Transfer (REST) over HTTP. By defining clear API endpoints, following the request-response cycle, transferring data in JSON format, and handling errors effectively, the codebase ensures seamless communication between clients and servers, facilitating the exchange of information and enabling the implementation of various features in the application.
Each and every endpoint expose from the API gateway is named using URI.
The route names in the services-routes.js files are descriptive and reflect the actions they perform. For example, /payment is used for processing payments, and /payment/:id/refund is used for initiating refunds. This will help to understand the purpose of each route quickly.
The use of parameters in route paths, such as :id in /payment/:id/refund, follows RESTful principles for resource identification. This allows for identifying specific resources (e.g., payments) using unique identifiers (IDs) in the URI. By doing this, code is predictable to utilize in the distributed system.
The separation of concerns between routes and controllers provides modular organization. Each file, such as payment-routes.js and paymentController.js ext., focuses on a specific aspect of the application (routing and business logic, respectively), promoting clarity and maintainability. This modular structure aligns with the principles of microservice architecture, where components are decoupled and independently deployable.
The system follows consistent naming conventions throughout. For instance, camelCase is used for variable and function names (processPayment, refundPayment), which is a common convention in JavaScript development. Consistency in naming conventions helps in reducing cognitive load for developers and ensures uniformity across the codebase. Example : /purchaseTicket - the enpoint which allows to buy tickets /login - the endpoint which can be used to login to the system
Controller function Names: The controller function names such as processPayment and refundPayment in the paymentController.js file are an example, and they are also descriptive and self-explanatory. These clearly indicate the actions they perform, which is according to the Single Responsibility Principle (SRP) by focusing on a specific task
In a EasyPass, fault tolerance is crucial to ensure uninterrupted service despite failures in individual components.
Database Replication: As mentioned earlier, the system employs database replication to maintain multiple copies of data across different nodes or replicas. If one database node fails, the system can seamlessly switch to another replica, ensuring data availability and continuity of service. Service Redundancy: Critical services such as payment processing, order management, and user authentication are deployed redundantly across multiple servers or containers. If one instance fails, traffic can be rerouted to the redundant instances, minimizing service disruption.
At a high level, the EasyPass utilizes a load balancer, specifically Nginx, to efficiently manage incoming internet traffic. Nginx acts as the gateway, directing requests to multiple instances of a React frontend application. These instances are dynamically scaled based on traffic thresholds using a provided script. Once traffic reaches a certain stage, it's routed through the API gateway for authentication and onward redirection to backend microservices. This load balancing approach ensures optimal resource utilization, scalability, and reliability for the entire system.
- The system has two types of users: "Guest Users" and "Admin Users".
- Guest Users can browse available events but need to register to reserve tickets.
- /register: Register a new user.
- /login: User login endpoint.
- Guest Users can view all registered events.
- /viewEvents: Retrieve all registered events.
- Admin Users can add, delete, or modify events.
- /addEvents: Add a new event.
- /deleteEvents: Delete an existing event.
- /updateEvents: Modify an existing event.
- Admin Users can manage tickets for events.
- /addTicketsToEvent: Add tickets to an event.
- /updateTickets: Update ticket details.
- /deleteTickets: Delete tickets from an event.
- Users can check ticket availability.
- /ticketAvailability: Retrieve available ticket count.
- Users can reserve and pay for tickets using the system.
- /purchaseTicket: Reserve and pay for tickets.
- Users can also request refunds for their payments.
- /refundPayment: Process refund requests.
- Upon successful payment, order details are sent to the user.
- The system uses JWT-based authentication. Users need to log in to perform certain actions, and there's middleware to handle authentication (authMiddleware).
- Users can reserve tickets for events (reserveTickets function). The system checks ticket availability and reserves tickets accordingly.
- After ticket reservation, the system processes payments (processPayment function). It associates the payment with the user and the order.
- Once payment is processed, the system manages the order (manageOrder function). This likely includes updating the status of the order and associating it with the user and the purchased tickets.
- Admins can initiate refunds (/refundPayment endpoint). This involves updating the payment status and potentially releasing reserved tickets.
- Users can register (/register endpoint) and log in (/login endpoint). Admins are differentiated and have additional privileges.
- Admins can add, update, and delete events (/addEvent, /updateEvent, /deleteEvent endpoints). They can also manage tickets associated with events.
- Admins can add, update, and delete tickets (/addTicketsToEvent, /updateTickets, /deleteTickets endpoints). They can also view ticket availability for events (/ticketsAvailability endpoint).
- Users can view available events (/viewEvents endpoint).
- The system provides appropriate error messages and handles internal errors gracefully.
- The API gateway communicates with various microservices (user, ticketing, payment, event, order management) to perform actions. It abstracts away the complexities of direct communication with these services.
The given GitHub repository contains all the necessary files for building the EasyPass application. The repository includes two directories: FEbrifge (FrontEnd Bridge) and Services. Both directories represent the two nodes of the system. Additionally, the Firebase database serves as the third node for storage. The application code is implemented with a focus on hosting it in an AWS-based Linux environment.
To initiate the deployment process, two EC2 instances will be required for the two directories in the repository:
- Node 1 (Instance 1) - Load Balancer, Multiple Frontend Instances, and API Gateway
- Node 2 (Instance 2) - 5 microservices
- Node 3 - Firebase database
The EasyPass application backend consists of 5 Node.js services: Auth-service, event-catalog-service, order-management-service, payment-service, and ticketing-service. While ideally each microservice can operate on separate nodes/machines, resource constraints dictate that all five services will be deployed on a single EC2 instance. To ensure availability, pm2 is utilized as the service manager.
Clone the repository
Git clone https://github.com/Shazam007/Distributed-E-Ticketing.gitcd into the Services directory
cd ./Distributed-E-Ticketing/Services Give permission to run the automation script service_runner.sh
chmod +x service_runner.shRun the service_runner.sh
./service_runner.shAccept the console pop ups to uninterrupted install
At the end of the script, all 5 services will be running on ports (3001,3002,3003,3004,3005)
To see the running service list, use
pm2 list Make sure to add those ports to the security group to accept the traffic from other instance (Add that instances IP as the source).
To direct traffic from the internet to the frontend applications and evenly distribute it among them, Nginx serves as the server. The frontend is a React application built with Vite, and initially, the provided script can be employed to create two application copies on different ports, functioning as two hosts. The script possesses the ability to scale up or down (adding more frontend instances) the React application based on traffic compared to a selected threshold. In the final stage of this node, the traffic will be routed to the API gateway. From there, all requests will undergo authentication and be redirected to the relevant services, serving as a bridge between frontend and backend microservices.
Clone the repository
Git clone https://github.com/Shazam007/Distributed-E-Ticketing.gitSetup Nginx
cd into the Nginx directory
cd ./Distributed-E-Ticketing/FEBridge/Nginx-LB Give permission to run the automation script
chmod +x nginx_setup.shRun the script to install and configure nginx
sudo ./nginx_setup.shConfigurations aim to route the traffic to the initializing frontend services in next steps. Also open the TCP 80 port in security groups to accept the incoming HTTP traffic.
Setup Frontend services
cd into the FE directory
cd ./Distributed-E-Ticketing/FEBridge/Frontend Give permission to run the automation script
chmod +x setup_frontend.shRun the script ./setup_frontend.sh
sudo ./setup_frontend.shThis will spin up two frontend applications on ports 3001 and 3002, along with a pm2 service to monitor the instance traffic for scaling up or down the instances. The script is designed to duplicate the directory (or delete if scaling down), assign an available port to the application, and then add it to the load balancing roster of the Nginx server.
As the last component in the node, the API-gateway needs to initiate.
cd into the FE directory
cd ./Distributed-E-Ticketing/FEBridge/EasyPass-api-gatewayMake sure to add the other instance’s (node with all microservices) IP to the .env to build the communication.
Give permission to run the automation script
chmod +x setup_gateway.shRun the script ./setup_gateway.sh
./setup_gateway.shJMeter has been utilized for obtaining results and evaluation, as it allows us to measure latency, throughput, and conduct load testing effectively.
NN group , and this research artical have shown that user attention and satisfaction can significantly drop if a task exceeds the approximate 10-second threshold. This is the point at which users begin to lose focus and may consider leaving the process. This effect is particularly considered on e-commerce and ticketing platforms.
Simple endpoints, such as "Add Event," "Login," and "View Event," typically involve straightforward database queries or minor processing, leading to lower latency. Conversely, complex endpoints, like "Refund Payment," and "Purchase Ticket," involve multiple steps, internal service calls, and more intensive database operations, thereby justifying higher latency.
| Endpoint | Latency (ms) |
|---|---|
| Add Event | 581 |
| Login | 625 |
| Purchase Ticket | 978 |
| Refund Payment | 1031 |
| Register | 350 |
| View Event | 626 |
Throughput assesses the volume of transactions processed within a given timeframe. Similar to latency, complex endpoints, such as "Refund Payment" and "Purchase Ticket," show lower throughput values, whereas other endpoints tend to display comparatively higher throughput values.
| Endpoint | Throughput (messages/s) |
|---|---|
| Add Event | 1.6 |
| Login | 2.9 |
| Purchase Ticket | 1 |
| Refund Payment | 0.97 |
| Register | 1.6 |
| View Event | 1.4 |
Load testing enables the evaluation of how the application performs under heavy loads. This includes understanding how quickly the system responds to requests, which is vital for user satisfaction and retention. For our project, we conducted two types of load testing: initially with just one user, and subsequently with 10 concurrent users. The single-user test helped us observe how the system operates under optimal conditions. Following this, we introduced 10 users to more accurately simulate real-life usage and identify any issues that arise when the system is used by multiple people simultaneously. This approach helped us determine whether our project can efficiently handle multiple users without encountering problems.
| Endpoint | Throughput (messages/s) (1 Users) | Latency (ms) (1 Users) | Avarage Throughput (messages/s) (10 Users) | Avarage Latency (ms) (10 Users) |
|---|---|---|---|---|
| Add Event | 1.6 | 581 | 1.1 | 429.2 |
| Login | 2.9 | 625 | 1.1 | 379.6 |
| Purchase Ticket | 1 | 978 | 1 | 860.8 |
| Refund Payment | 0.97 | 1031 | 1 | 1047.8 |
| Register | 1.6 | 350 | 1.1 | 843.5 |
| View Event | 1.4 | 626 | 1 | 127.2 |
The difference in latency between single-user and multi-user scenarios varies. We cannot definitively state that multi-user scenarios always exhibit higher latency. Endpoints involving complex transactions or database writes tend to demonstrate increased latency under load, aligning with expectations.
The difference in throughput between single-user and multi-user scenarios shows some deviations, meaning that single-user scenarios exhibit higher throughput than multi-user scenarios. This is an expected scenario, as the number of users increases, the number of messages processed within a given time decreases.
This project was carried out as a requirement for the course 521290S Distributed Systems in Faculty of ITEE of University of Oulu. All the work was carried out under the instructions of the respective lecturers of the course.