Evaluating Middleware Performance in the Transition from Monolithic to Microservices Architecture for Banking Applications

Abstract

The swift development of digital financial services has increased transaction volumes and heightened system performance requirements. Cardless cash deposit transactions at PT Bank XYZ have significantly increased since 2022. This growth necessitates an evaluation and improvement of the existing system architecture. This study proposes a microservices-based architecture deployed in a middleware environment to enhance performance, scalability, and availability. Key enhancements include asynchronous service processing, dual-layer authentication, and data caching using the Terracotta Server Array. The evaluation uses metrics such as CPU usage, RAM usage, latency, throughput, error rate, success rate, and recovery time. Both the monolithic and microservice architectures were assessed through stress testing. Tools used include Red Hat OpenShift Dashboard, NMon Visualizer, and Apache JMeter. Results indicate that the microservices architecture outperforms the monolithic architecture by delivering better resource efficiency, lower latency, higher throughput, and faster recovery times. Moreover, implementing dual-layer authentication enhances security without significantly increasing system complexity. The findings confirm the long-term viability of the microservices architecture for high-demand financial applications.

1. Introduction

Digital banking has transformed financial services, driving greater focus on security, performance, and scalability. Cardless cash deposit services now offer customers more convenience and lower security risks than traditional card-based transactions. Since launching in 2022, this service at PT Bank XYZ has grown rapidly, increasing demands on system architecture to handle rising transaction volumes efficiently.

PT Bank XYZ has traditionally used a monolithic architecture, in which every component of the application is tightly coupled into a single deployable unit. Early implementation of such architecture is straightforward. However, as the architecture grows more complex and is used more widely, it develops inherent problems. Long development times, difficulty identifying errors, the requirement for complete redeployment after small code changes, and resource constraints under heavy load are typical issues [1]. Scaling monolithic architectures is more difficult because applications must be scaled as a single unit, which can lead to higher hardware usage than with microservices [2].

Microservices architecture (MSA) has emerged as an effective alternative. It decomposes applications into smaller, independent services, each representing a distinct piece of application functionality. These services can be developed, deployed, and scaled autonomously [3]. This modularity allows teams to innovate faster, use technology stacks tailored to each service, and improve fault isolation (the ability to prevent failures in one service from affecting others) [4]. Previous research in finance has shown that microservice architecture can improve system performance by reducing latency, increasing flexibility, and improving operational efficiency. Furthermore, microservice architecture enables real-time data processing and delivery, maintaining system responsiveness under high loads [5]. In cloud-based implementations, monolithic and microservice architectures developed with Kubernetes have been shown to reduce response times and increase system throughput. The study found that implementing scalable workloads on Kubernetes reduces response times by around 25 percent and increases system throughput, regardless of whether the architecture is monolithic or microservice [6]. Microservices have improved performance. Over several months, observations show lower response times, suggesting microservices handle higher transaction volumes effectively. At PT Bank XYZ, the migration of several services from a monolithic to a microservices architecture has demonstrated notable performance improvements. As shown in Figure 1, the microservices architecture consistently delivers lower response times compared to the monolithic architecture over several months of observation, indicating its capability to handle high transaction volumes more efficiently.

The comparison in Figure 1 clearly illustrates the performance advantage of adopting microservice architecture over traditional monolithic architecture. The consistently lower response times achieved by the microservices architecture indicate its ability to process transactions more efficiently, especially under increasing user demand and higher transaction volumes. This improvement enhances the user’s experience by enabling faster delivery service. It also reduces operational strain on backend systems. By distributing workloads across independent services, the microservices architecture minimizes the bottlenecks common in monolithic architectures. This improves overall system resilience. Furthermore, the enhanced modularity enables targeted scaling of specific services based on demand. As a result, resource utilization and long-term operational efficiency in banking have been further improved, bolstered by middleware technologies. To improve services, real-time data processing, and system resilience, a microservice-based middleware architecture is used that utilizes an API Gateway to manage services [7]. It has been shown that implementing layered authentication and authorization with dedicated authentication microservices and an API gateway improves system security while maintaining acceptable response times and performance [8].

Evaluation results from previous research involving 1 to 50 users showed that microservice architectures handled increased workloads more effectively than monolithic architectures, maintaining lower response times and better performance stability under high workloads [9]. High performance in MSA (Microservices Architecture)-based transaction systems has also been found to be significantly facilitated by non-blocking I/O operations (input/output operations that do not halt program execution while waiting for data) and asynchronous communication patterns (methods where services interact without waiting for each other’s immediate response) [10]. Nevertheless, the shift presents difficulties. It adds complexity to data consistency management, inter-service communication, and distributed monitoring.

This study assesses the performance, scalability, and availability of microservices compared to monolithic architectures in the cardless cash deposit service at PT Bank XYZ. The evaluation considers these factors. The assessment uses performance metrics such as throughput, error rate, success rate, recovery time, latency, and CPU and RAM utilization. On-premises middleware environments are used for load and stress testing. Tools such as Red Hat OpenShift Dashboard, NMon Visualizer, and Apache JMeter are employed. By balancing performance, security, and scalability in high-demand banking systems, the findings are intended to help financial institutions make well-informed architectural decisions.

Monthly transaction statistics for PT Bank XYZ’s cardless cash deposit feature are shown in Figure 2 to further highlight the scale of service utilization. Between August 2023 and March 2024, this chart shows the total number of transactions and the number of successful transactions.

The number of successful transactions and the total monthly transactions have remained high throughout the observation period, as shown in Figure 2, and both measures are closely linked. Peak transaction volumes in December 2023 and March 2024 are shown in the statistics, indicating that users are increasingly using the service. The minimal gap between total and successful transactions also reflects the system’s high reliability and the effectiveness of its supporting architecture in maintaining service continuity, even during periods of increased demand.

Previous studies commonly evaluate general banking services on cloud servers; this study evaluates a specific cardless cash deposit service with high transaction volume, running on-premises and leveraging Service-Oriented Architecture-based Server Integration technology and API Gateway management to support microservices architecture. Furthermore, the metrics used in some previous studies remain limited, focusing only on latency and throughput, without accounting for resource utilization and recovery time.

System optimization is critical for improving efficiency and reliability in financial technology. Recent fintech research using MLSTM-based prediction models with IBFO and modified WOA demonstrates how targeted resource management reduces computational complexity and processing load [11]. These advances show that financial systems, such as banking and fintech, achieve greater stability and efficiency by conserving resources while maintaining system reliability, aligning directly with the objective of this study.

2. Related Work

It is crucial to review prior research on the relative benefits and challenges of monolithic and microservice architectures to provide this study with a firmer foundation. These studies span a wide range of topics, including cloud-based environments, enterprise web applications, and banking systems. However, they all aim to evaluate architectural performance, scalability, resource use, and system stability. The examined works use a variety of techniques, such as stress testing, experimental benchmarking, and scalability assessment, and frequently utilize essential performance metrics, including CPU and memory utilization, latency, throughput, error rate, and success rate.

Some studies focus on the banking industry, where stringent service continuity regulations and high transaction volumes make scalability and reliability crucial. Others investigate more expansive enterprise situations, assessing architectures in various deployment settings, programming languages, and integration technologies. The results show that microservices are superior at managing complex, high-demand systems because they provide greater modularity, fault isolation, and the ability to scale individual services independently, whereas monolithic designs may be more effective in basic or low-scale applications.

Several publications examine security considerations alongside performance evaluations, including the integration of contemporary middleware components such as Service-Oriented Architecture (SOA) and API Gateways, as well as the use of dual-layer authentication. These improvements reinforce microservices’ operational benefits, including maintainability, flexibility, and fault tolerance.

Several studies have shown that microservices applications outperform monoliths under high workloads, particularly in terms of average response time. Other studies have combined microservices and API Gateways to improve security and service traffic management, demonstrating the ability to mitigate the impact of attacks such as espionage and man-in-the-middle attacks. API Gateway implementations using caching and throttling technology have been implemented by companies such as Netflix, Twitter, and NASA.

Several studies have compared microservice and monolithic architectures in terms of scalability, performance, and resource usage in applications such as banking and web applications as shown in

Table 1. Summary of Related Study.

Ref No	Research Title	Method	Test Results	Proposed Model
Maestro and Surantha, 2023 [12]	Scalability Evaluation of Microservices Architecture for Banking in Public Cloud	Scalability Evaluation includes CPU, Memory, Latency, Nodes, and Error Rate.	Microservice architecture is superior in resource utilization	Microservices on Google Cloud Kubernetes with dual-layer WAF and NGFW security.
Blinowski et al., 2022 [13]	Monolithic vs. Microservices Architecture: A Performance and Scalability Evaluation	Performance comparison of monolith and microservices includes Throughput, CPU, and RAM on each architecture, technology, and computer.	Monolithic architecture is superior to simple systems	The application is implemented on monolith and microservice architectures and uses Java 84 with Spring Boot framework 2.3.0 and .NET implemented in C# version 8 with ASP.NET Core framework 3.1.
Barczak et al., 2021 [14]	Performance comparison of monolith and microservices-based applications	Performance comparison of monoliths and microservices includes RAM, CPU, and service response time.	Monolith architecture is superior in the context of average response time.	Web implementation on two different architectures with analysis using Azure Application Insights module
Dhaouadi et al., 2021 [15]	Benchmarks and performance metrics for assessing the migration to microservice-based architectures	Microservice performance assessment includes latency, throughput, scalability, CPU, memory, and network utilization.	Monolith architecture is superior in simple systems, but microservices are superior in scalability.	Implementation of microservice and monolith architectures on local servers and clouds.
Ramu, 2023 [16]	Performance Impact of Microservices Architecture	Microservice performance evaluation includes response time, throughput, and error rate.	Resulting in shorter response times on microservices	Microservice performance improvement strategies include gRPC, instance scalability, cache, containerization, NoSQL, and asynchronous communication.
Banerjee, 2024 [17]	System Integration, From Middleware to API	Descriptive and evaluative approach with qualitative analysis, case studies, and the author’s experience to examine the evolution of system integration technology.	The evolution of system integration from middleware to modern APIs with microservices to increase flexibility, scalability, and efficiency in digital transformation	Composable Enterprise that leverages APIs, microservices, and Event-Driven Architecture (EDA).
Dheeraj Konidena, 2024 [18]	Securely Running High-Performance Workloads as Microservices in Cloud Environments	Qualitative data collection by interviewing cloud security experts, and quantitative data collection by benchmarking the performance of monolithic and microservice applications in the cloud.	Microservice architecture in the cloud reduces CPU usage by 21% and memory by 12% and speeds up response time compared to monolithic architecture with stronger security systems.	A cloud microservice integration framework that combines security, containerization, and Kubernetes to improve system efficiency, scalability, and resilience.
Yang et al., 2021 [19]	User Fast Authentication Method Based on Microservices	Comparing tiered and conventional authentication in terms of performance	Redis-based tiered authentication method improves performance by up to 50.22% on QPS 1000 compared to conventional database-based method.	Split authentication into two levels: advanced in API Gateway and basic in application server with Redis for abnormal user detection
Meenakshi Thalor, 2024 [20]	Analysis of Monolithic and Microservices System Architectures for an E-Commerce Web Application. International	Comparing monolithic and microservice architectures with parameters of average response time, minimum response time, maximum response time, standard deviation, error rate, throughput, and transmission speed. Testing was conducted using JMeter and Postman to simulate a high volume of transactions.	Microservices architectures have better response times and lower error rates than monoliths, but they also have higher minimum latency. Microservices architectures are considered more expensive due to their more complex configuration and hardware requirements than monoliths. This study found that microservice architectures are suitable for large applications.	Comparison of monoliths and microservices in e-commerce applications using Node.js and Express.js technology
Matias et al., 2024 [21]	Enhancing Effectiveness and Security in Microservices Architecture	Design and testing of API Gateway patterns with the use of HTTPS and JWT for transactions required with the NB-IoT communication protocol	System testing was conducted using security attack scenarios, including espionage and man-in-the-middle attacks. The results showed reduced internal communication latency, increased system efficiency, reduced system complexity, and maintained security under the assumption of a secure network.	Hybrid strategies can improve system performance, reduce communication latency between microservices, and increase security levels without reducing performance.

. The results of these studies indicate that microservice architectures have better scalability and performance than monolithic architectures under high transaction loads. However, most related research has been conducted in cloud environments and is limited to on-premises research, which has limited infrastructure and resource management. Some parameters used in previous studies include resources, throughput, latency, and error rate. However, very little research has addressed the time-to-recovery parameter, namely the system’s ability to recover after a disruption, which plays a crucial role in banking systems to increase availability and reliability. Therefore, this study was conducted in an on-premises environment and used more comprehensive parameters, including CPU usage, RAM, throughput, latency, error rate, success rate, and time to recovery.

Other studies have also explored API Gateway in microservice architectures, specifically to improve service traffic management and strengthen system security. Therefore, this study adopted API Gateway in a microservice architecture to evaluate its impact on system performance compared to a monolithic architecture. This study implemented two different authentication methods in the application access flow. However, security testing with attack scenarios on the system was not possible because the system was running on an active operational server, which posed a risk of service disruption.

Several previous studies have shown that API Gateway applied to microservices improves security and request distribution management in applications. In the journal “Systematic Review of API Gateway Patterns for Scalable and Secure Application Architecture” [22], several best practices for improving API Gateway security are described, including separating authentication logic, the token broker, and layered access control. The study did not implement a two-layer authentication mechanism, but it explained the best practice of separating authentication from routing logic using an identity provider and a token broker. The recommended best practices are implemented in this study by using authentication at two layers: layer 1 at the gateway level and layer 2 at the service level. In addition to security, API Gateway can improve resource efficiency by managing traffic and implementing caching, thereby reducing the processing load on backend services. Previous research titled “Improving Performance with API Gateway Caching and Throttling” [23] shows that implementing caching and throttling mechanisms in the API Gateway can improve system performance and reduce load on backend services.

3. Methodology

The architecture of the proposed system is microservices-based, as shown in Figure 3, and the main entry point for handling requests coming from the ATM or other front-end interfaces is an API Gateway. The API Gateway completes initial authentication, modifies the request and response formats if necessary, and then sends the requests to the relevant microservices for additional processing. To improve security without increasing computational complexity, an extra authentication step is performed at the application level.

Each pod that hosts the microservices encapsulates a unique service composition. Modular service orchestration is enabled by network communication between these pods within a single application environment. Two of the five service flows implemented run asynchronously, reducing latency and speeding up response times. Additionally, the architecture uses a Terracotta Server Array caching technology to increase throughput and reduce the frequency of database accesses.

The technology stack used in this investigation is shown in Figure 4 and consists of backend services, Service-Oriented Architecture (SOA) middleware, and an API Gateway. NMon Visualizer is used to track CPU and memory usage in a monolithic implementation; Apache JMeter is used for load and stress testing; and the OpenShift Dashboard is used to track resources in the microservices deployment to evaluate performance.

Each service pod was configured with 128 MiB of Random Access Memory (RAM), 250 millicores of CPU, and a Terracotta Server Array was used to support distributed caching. The service orchestrator, an Integration Server, facilitates communication between microservices and backend systems over the HTTP protocol.

CPU utilization, memory utilization, throughput, latency, number of instances, error rate, success rate, and time to recovery were among the performance indicators evaluated; they are summarized in

Table 2. Measurement parameters.

Parameter	Information
CPU Utilization	CPU and RAM measurements: monoliths with Nmon Visualizer, microservices with OpenShift.
Memory Utilization
Throughput	JMeter’s Summary Report feature measures the number of successfully executed requests.
Latency	JMeter’s timer feature measures the server’s response time to requests
Number of Instances	Instance count measurement: max 2 monoliths, max 4 microservices.
Error Rate	Comparison of total transactions and failed transactions (status ≠ 200) was performed 50 times in 10 s using the Summary Report feature
Success Rate	Comparison of total and failed transactions (success: status 200) was performed 50 times in 10 s using Summary Report
Time to Recovery System	The time it takes for an application to recover after going down.

. These measures offer a thorough evaluation of the suggested architecture’s resilience and efficiency. In particular:

• NMon Visualizer for monolithic systems and OpenShift Dashboard for microservices are used to measure CPU and memory utilization.
• To assess reaction time and processing capability, JMeter’s Summary Report is used to record throughput and latency.
• The number of instances measures how scalable each architecture is.
• Transactional accuracy and dependability in simulated operational settings are measured by error and success rates.
• Time to Recovery calculates how long it takes to get a system back up and running after an outage.

The suggested approach seeks to improve performance, scalability, and fault tolerance in high-demand banking systems by combining microservices with middleware and asynchronous processing, particularly for PT Bank XYZ’s cardless cash deposit service.

4. Results and Discussion

This section presents the results of evaluating monolithic and microservice architectures, supplemented by an interpretation of the test results and the conclusions that can be drawn based on the tested parameters.

4.1. Simulation Setup

Apache JMeter, NMon Visualizer, and the Red Hat OpenShift Dashboard were used for performance testing. Apache JMeter tracked throughput, latency, success rate, and error rate, whereas NMon Visualizer tracked CPU and memory usage for the monolithic architecture. Using the OpenShift Dashboard, resource usage for the microservices environment was tracked. With each scenario running for 10 s and being repeated 50 times, the tests were conducted at 30, 40, 50, 60, 90, and 120 transactions per second (TPS). This resulted in a total runtime of 500 s per scenario. Recovery time was determined by manually restarting the server, and system availability was assessed using success and error rates.

4.2. Performance Evaluation

Load testing at 90 and 120 TPS was conducted but was not included in the research results because the system began to experience application instability, characterized by increased error rates and inconsistent responses. Therefore, the performance analysis focused on the load range with a stable response.

4.2.1. CPU Utilization

According to Figure 5, CPU utilization in the microservices architecture was much lower, ranging from 8.65% to 16.84%, while in the monolithic system it ranged from 19.93% to 26.21%. The distributed, independently scalable structure of microservices results in a more efficient allocation of processing resources, as evidenced by a 40–50% decrease in average CPU load. Because it prevents undue processor strain as workloads grow, this efficiency is especially crucial for high-demand financial systems. This lowers the risk of service outages or performance degradation. The reported CPU reductions in this on-premises implementation are higher than in previous research on cloud-based microservices, suggesting that resource efficiency can be further improved by localized processing combined with better service orchestration.

4.2.2. Memory Utilization

Figure 6 shows that the microservices architecture ranged from 21.87% to 23.27%, whereas the monolithic architecture maintained an average memory consumption of 54.10% to 54.20%. This decrease of over 30 percentage points highlights the benefit of dividing services into separate pods, which enables more focused scaling and eliminates the need to allocate memory resources to irrelevant tasks. In addition to lowering operating expenses, lower memory usage enables more services to run simultaneously on the same hardware, which is essential for ensuring scalability without over-provisioning hardware.

4.2.3. Latency

Latency response times for the microservices implementation ranged from 502 ms to 838 ms, whereas the monolithic design produced response times between 492 ms and 740 ms, as shown in Figure 7. Asynchronous service execution and caching techniques help mitigate the overhead of interservice communication in microservices. However, Figure 7 shows a latency of 838 ms in microservice architecture at the highest load, and 740 ms in monolithic architecture. The increase in latency is due to the microservice architecture, which is implemented as independent services that require network communication, as explained in the study “Optimized Strategy for Interservice Communication in Microservices” [24]. The latency difference at high loads is attributable to microservices overhead at peak load, due to additional network hops.

4.2.4. Throughput

The microservices architecture achieved 29–59 requests per second (rps), whereas the monolithic system’s throughput ranged from 27 to 52 rps, as shown in Figure 8. The scalability advantage of microservices under concurrent transaction loads is validated by the 10–15% increase in throughput. This enhancement is attributed to the architecture’s ability to dynamically scale certain services in response to demand, thereby maximizing server resource utilization and reducing queue buildup during periods of high transaction volume. In banking settings, where transaction spikes often occur during salary disbursements, holidays, and promotional activities, such performance increases are particularly valuable.

4.2.5. Rates of Success and Error

All test cases were successfully completed by the monolithic design, whereas the microservices implementation had an average success rate of 98.58%. This difference in success rates is due to resource limitations in high-load scenarios and is not a weakness of each architecture. A similar condition also occurs in the study “Performance Comparison of Monolithic and Microservices Architectures in Handling High-Volume Transactions” [20], where, under high transaction loads, the error rate difference in the microservices architecture increases from 71% lower than in the monolithic architecture to 35% lower. In this study, the error rate is below 3%, which is lower than that observed in comparable microservices installations on public cloud platforms, where error rates can exceed 5% under similar loads. The 1.42% error rate difference is still within a reasonable range in high-load testing and does not indicate any architectural design weaknesses, except for system resource limitations. These results highlight the suitability of on-premises microservices for critical financial applications, where reliability is critical.

4.2.6. Recovery Time

Microservices showed a recovery time of 83.3 s in system recovery testing, while the monolithic design took 215 s. The microservices environment’s smaller deployment packages, 52 separate service packages spread across several instances, as opposed to the monolithic design’s single, massive package of 285 components, are primarily responsible for this 61% improvement. In addition to reducing downtime expenses, faster recovery also reduces the risk of transaction backlogs during restoration.

4.2.7. Analysis

A comparison with earlier studies on microservices and monolithic systems was made to put the performance increases seen in this study into perspective. Key performance data, such as CPU and memory utilization, latency, throughput, number of service instances, and error rates reported in related studies, are compiled in

Table 3. Comparison test result.

Related Study	Experimental Results Summary
Scalability Evaluation of Microservices Architecture for Banking in Public Cloud	Microservices with 10K, 30K, 50K hits. vCPU: 0.27 to 0.41 Memory: 0.14 to 0.26 Latency: 99.02 to 332.84 Throughput: 99.75 to 487.56 Number of Instances: 1.8 to 3.8 Error Rate: 0 to 67.18
Securely Running High-Performance Workloads as Microservices in Cloud Environments	Implementation of a deeper security system in the microservice architecture is better by 21% CPU usage and 12% memory usage. CPU Utilization: Monolith 71% Microservice 54% Memory Usage: Monolith 2048 MB, Microservice 1527 MB Response Time: Monolith 252 ms, Microservice 179 ms
User Fast Authentication Method Based on Microservices	Multilevel authentication by utilizing JWT authentication technology and Redis as storage for abnormal user data can improve performance from 15.25% to 50.22% compared to conventional database-based technology.

. These standards provide a basis for assessing the effectiveness, scalability, and dependability of the suggested architecture, drawing on accepted research. In addition to highlighting the performance advantages, the comparison also identifies architectural techniques that have helped optimize performance in previous efforts, including dual-layer authentication, caching systems, and asynchronous processing.

Compared to the conventional monolithic design, the performance evaluation unequivocally shows that the proposed microservices architecture offers greater resource efficiency. Previous studies have similarly documented reduced CPU and memory usage after monoliths are broken down into microservices; this conclusion is supported by an industrial case study tailored to the financial services industry [25].

The study’s latency measurements show that the extra burden typically introduced by inter-service communication in microservices is effectively offset by integrating asynchronous processing and distributed caching technologies (such as the Terracotta Server Array). This is consistent with research on performance-oriented architecture design, which shows that microservice design patterns, such as Pipe-and-Filter and Gateway Aggregation, can maintain balanced resource usage and service latency across a range of workloads [26].

The microservice architecture exhibited a maximum latency of 838 ms at a load of 60 TPS, as shown in Figure 7. Latency comparison between monolithic and microservices architectures. This represents a transient peak system capacity and does not reflect the average latency at lower loads. The results show that the latency generated by the microservice is comparable to that of the monolithic one and even tends to be lower at loads below 60 TPS. This indicates that the system performance is stable under normal conditions. Latency spikes at maximum load can occur due to temporary bottlenecks caused by communication overhead between services in the microservice architecture, especially during high-load testing. The presence of concurrent processes also contributes to increased latency at peak conditions near the system capacity limit. However, this condition does not significantly affect throughput or the microservice architecture’s success rate.

It is also possible to contextualize the throughput benefits shown here more comprehensively. Microservice-based prototypes outperformed monolithic systems in an experimental assessment of high-volume transaction processing, achieving 71% fewer errors and 36% faster response times under high load [27]. Our controlled on-premises deployment demonstrated robust scalability without encountering such limits, even though the study showed performance decreased when CPU utilization exceeded 90%.

Because it centralizes cross-cutting concerns such as authentication, routing, load balancing, and caching, API Gateway performs a crucial orchestration role. Empirical research highlights the significance of efficient caching and throttling in API gateways: caching can achieve much lower latency and reduced backend load, while throttling safeguards backend services during traffic spikes [23]. This is the technical background for how our API Gateway design helped maintain performance stability amid rising transaction traffic.

In conclusion, the use of microservices in conjunction with SOA middleware, asynchronous processing, and a well-designed API Gateway creates a reliable and effective architecture suitable for high-demand banking applications such as cardless cash deposits. This conclusion is supported by the collected data. This architecture maintains acceptable latency and low error rates while providing observable improvements in resource utilization, throughput, and resilience.

4.2.8. Discussion

System Performance and Scalability

Overall, while maintaining competitive latency, the suggested micro-services-based architecture outperforms the conventional monolithic design across key performance metrics, including resource consumption, throughput, and recovery speed. Microservices’ modularity enables accurate CPU and memory resource allocation based on workload demands, minimizing waste and avoiding bottlenecks. Better load distribution across multiple service instances is enabled by the architecture’s dynamic scaling, which enhances system responsiveness during high demand.

The Role of Distributed Caching and Asynchronous Processing

Performance improvement was greatly aided by the Terracotta Server Array’s incorporation of a distributed caching system and asynchronous service processing. These elements allowed the system to process requests in parallel without compromising consistency, decreased reliance on synchronous database calls, and decreased network wait times.

Security and Performance Trade-Off

The advantages of microservices’ scalability, efficiency, and resilience exceed the slight variation in success rate, even though the monolithic architecture maintained a 100% success rate. Without causing appreciable latency, security has been further enhanced by implementing a dual-layer authentication system at the service and API Gateway levels.

Implications for the Financial System

The suggested method offers a more balanced trade-off between security and performance and shows lower error rates than cloud-based microservice installations in previous studies. These findings demonstrate that the architecture is especially well-suited for financial services with high demand, offering scalability and sustainable operating efficiency while maintaining data security and dependability.

The results of the study indicate that system optimization can improve system performance, as evidenced by microservice architecture tests that tend to be superior to monolithic architecture, although some tests at the highest load experienced a decline. However, this is still within a reasonable and acceptable range. This finding aligns with research on financial systems and fintech, which emphasizes the importance of system optimization to improve efficiency, stability, and reliability in banking systems that require high availability and resilience.

5. Threats to Validity

This study has several limitations. The first test was conducted on an on-premises server, requiring adjustments and caution when applied to a cloud server. Second, due to the API Gateway implementation in microservice architecture, security testing could not be performed because it was conducted on an on-premises server in an active operational environment, thereby creating a risk of system disruption and failure. Furthermore, the 90-120 TPS load testing planned in the methodology was not included in the analysis because the system began to exhibit instability at 90 TPS. Therefore, the analysis includes loads under stable conditions. Finally, this study did not include further statistical analysis, so the evaluation results are still descriptive

6. Conclusions

The research findings indicate that the proposed microservices-based architecture for PT Bank XYZ’s cardless cash deposit service offers several advantages over the conventional monolithic approach. Under different transaction loads, the microservices implementation showed reduced CPU and memory usage, indicating greater resource utilization efficiency. Because of this efficiency and the modularity of architecture, services can be independently scaled to match changes in demand without using excessive resources.

During testing, the microservices environment demonstrated a faster recovery time after server outages, despite the monolithic design achieving somewhat greater availability. The smaller, more effective microservice deployment packages, which enable quick service restoration and reduce operational interruptions, largely contribute to this improvement.

Because the API Gateway’s conversion of requests to the middleware layer did not lead to noticeable variations in response times, message format modifications were possible without sacrificing efficiency. Maintaining interoperability across many client applications and backend systems is made easier with this feature. Additionally, the flexible use of service instances demonstrated the greater scalability of the microservices design, enabling focused scaling of individual workloads rather than the entire program.

The microservices deployment’s low error rate, even lower than that of similar studies, indicates the architecture’s dependability in a real-world banking setting. Finally, using a dual-layer authentication technique improved security without requiring extra or complicated technology. It was also efficient.

To summarize, the shift from monolithic to microservices architecture has resulted in observable improvements in maintainability, scalability, and performance while maintaining security compliance. These results suggest microservices as a viable architectural option that can be sustained for high-demand financial services. Future studies should focus on assessing cost–benefit trade-offs in hybrid cloud deployments, minimizing inter-service communication latency, and investigating advanced fault-tolerance techniques to further enhance system resilience.