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 modes that must be managed.
Abstract
Microservices architectures are widely adopted for their promised scalability and modularity, yet empirical evidence comparing their runtime performance to monolithic designs remains context-dependent. This paper presents an experimental comparison of a monolithic and a microservices implementation of the same e-commerce application, both backed by a shared PostgreSQL database. Using k6, we subject both systems to identical HTTP workloads at 50 and 100 virtual users (VUs) over 60-second runs, measuring throughput, latency, and error rates. At 50 VUs, both architectures perform similarly with no errors. At 100 VUs, the microservices design achieves 5.4% higher throughput, 25% lower average latency, and 39% lower p95 latency than the monolith, while exhibiting a lower median error rate (0.00% vs 0.69%). The monolith shows consistent order-creation failures under load, whereas microservices failures are transient and confined to the cart service in one run. These results suggest that, in this deployment context, decomposing the system into microservices improves scalability and tail latency under stress, while introducing distinct, service-specific failure modes that must be managed.
This research will perform a comparative evaluation of monolithic architecture and microservices architecture with a focus on their performance and cost characteristics to help developers to choose one of the styles considering its performance and cost characteristics.
R. Rautela, Abhisekh Mishra, Aditya Pandey et al.· International Journal of All...· 0 citations
This study compares the implementation of the same backend system, Node.js/Express and MariaDB, in a monolithic and microservices architecture with the same Docker resource allocation, 2 CPUs and 512 MB RAM per architecture, except database containers.
Yoga Ari Tofan· JUTI: Jurnal Ilmiah Teknolog...· 0 citations
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.
Novika Natalia, Rahmat Yasirandi, Sheina Fathur Rahman· International Seminar on Int...· 0 citations
This paper presents a systematic, practice-driven evaluation of WebAssembly (WASM) as an execution substrate for cloud-native workloads orchestrated through Docker and Kubernetes using runwasi. We develop a reproducible workflow that compiles Rust and Go/TinyGo applications to WASM modules, applies Ahead-of-Time (AOT) optimizations per engine and architecture, and packages minimal OCI artifacts for multi-architecture deployment (amd64, arm64, riscv64). Through controlled experiments on heterogeneous nodes, we benchmark eight CPU-bound workloads, reporting mean, median, and confidence intervals to ensure statistical robustness. The results show that WASM achieves latencies close to native on amd64/arm64, with WasmEdge leading under AOT and Wasmtime offering strong compatibility and stability. Artifact sizes are substantially smaller than traditional containers, improving pull times and packing density. While riscv64 execution is feasible, it remains less mature and more sensitive to engine and build choices. Overall, the findings demonstrate that WASM is a viable and efficient option for Cloud Continuum environments when deployments rely on AOT-optimized artifacts, RuntimeClass-based scheduling, and workloads aligned with the WASI feature set supported by the selected engines.
Álvaro Vázquez-Rodríguez, David Vila-Pérez, Carlos Giraldo-Rodíguez et al.· International Conference on...· 0 citations
This paper analyzes the two software architectural approaches namely Monolithic Architecture vs Microservices Architecture when considering scalable software development, and puts the following into consideration: empirical trade-offs, scalability consideration, organizational implications, and development complexity.
Theophilus Bamise Ajala, A. Oduroye, I. Ayoade et al.· Asian journal of applied sci...· 0 citations
The selection of communication protocols and underlying concurrency models profoundly impacts the performance and resource efficiency of microservice architectures. While existing studies frequently compare protocols like REST and gRPC, they often overlook the compounded effects of language-specific I/O paradigms during complex service chaining, as well as system behavior under edge-case failures. This study evaluates the performance disparities between Blocking I/O (Java Spring Boot) and Non-Blocking I/O (Python FastAPI) architectures utilizing REST and gRPC protocols. A containerized educational platform, simulating a three-tier service chain, was developed and subjected to rigorous load testing and fault injection scenarios. System performance was measured across varying payload sizes (1 KB, 50 KB, and 1 MB) to capture P99 latency, request throughput, CPU utilization, and memory footprint. The empirical findings indicate that while gRPC over HTTP/2 significantly enhances throughput, its efficiency is heavily modulated by the host language's thread management and serialization libraries. Furthermore, we identify the exact payload crossover threshold where multi-threaded blocking models outperform asynchronous event loops and analyze system resilience during simulated network partitions. The findings provide reproducible guidelines for software architects in selecting optimal protocol-language combinations, balancing raw performance with cognitive burden and fault tolerance.
A. Noertjahyana, Kartika Gunadi, Joseph Justin Harsono et al.· International journal of re...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
