Jul 2026· International Seminar on Intelligent Technology and Its Applications· pp. 322-327· 0 citations· 20 references
Abstract
API Gateway selection is a critical architectural decision in microservices systems, yet empirical comparisons between competing gateway strategies are scarce, particularly for PHP-based systems at the SME scale. This study presents a comparative performance analysis of three API Gateway implementations within System XYZ, a veterinary clinic management microservices architecture: No Gateway (direct client-to-service), Kong Gateway (third-party), and Native (Laravel). Performance testing was conducted using Apache Bench across three endpoints and three workload levels with three runs each. All 81 runs recorded zero failed requests. No Gateway consistently achieved the highest throughput (up to 6.68 req $/ \mathrm{s})$ and the lowest mean response time across all scenarios. Kong Gateway introduced minimal overhead on complex queries (0.6-8.3%) but exhibited severe latency spikes due to connection pool exhaustion and required significantly more memory (1.0-1.4 GB) than No Gateway (142-173 MB) and Native (149-238 MB) when backed by a single-threaded PHP server. Native incurs approximately three times higher response time for simple and filtered queries, and approximately two times higher for complex queries, due to the double PHP-hop overhead. These findings may inform developers of small-scale Laravel microservice systems in selecting the appropriate API Gateway strategy.
Cloud-based applications require architectures that can maintain efficient application loading and performance as workload increases. This study developed and experimentally evaluated three functionally equivalent e-commerce implementations: Monolithic, Baseline Microservices, and Proposed Microservices architectures....
Ikediego Henrietta Onyinyechi, A. Godspower, Chekwube Georgina Nwankwo et al.· International journal of re...· 0 citations
This paper presents a controlled comparison of exactly-once Kafka pipelines implemented with Apache Flink and Kafka Streams, two engines with different state-management architectures. The state management in Flink occurs through checkpoints in external storage, whereas Kafka Streams restores local state by replaying br...
Kiran N. Kumar, Santhoshkumar Saminathan· International Journal of Com...· 1 citation
An experimental comparison of a monolithic and a microservices implementation of the same e-commerce application, both backed by a shared PostgreSQL database, suggests that decomposing the system into microservices improves scalability and tail latency under stress, while introducing distinct, service-specific failure...
The consolidation of Large Language Models (LLMs) as active components in software development has exposed critical limitations in the traditional two-tier client-server architecture, which was not designed to manage programmatic credentials of high sensitivity, orchestrate concurrent calls to heterogeneous external to...
The aim of the study is to estimate the resource cost of using KubeEdge on top of K3s under an identical microservice workload that emulates V2X message processing and to establish a baseline for subsequent evaluation of service placement algorithms.
G. Tambovtsev, A. Vladyko, P. Plotnikov· Proceedings of Telecommunica...· 0 citations
The central argument is that serverless ETL does not simplify data engineering; it redistributes engineering effort from infrastructure management to execution model design, and Lambda timeout decomposition, cold start management, Glue worker right-sizing, IAM role scoping, and Step Functions state machine cost design...
Rambabu Bolineni· East African Journal of Info...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.