Tail latency, throughput, and memory overhead of monolithic and microservices architectures in resource-constrained docker deployments

An Empirical Comparison of Monolithic and Microservices Architectures for an E-Commerce Application

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.

Performance Evaluation of API Gateways in Microservices System: No Gateway, Kong, and Native

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.

Analysis of Microservice Approaches to V2X Systems with Edge Computing

Relevance . The development of V2X systems and the migration of computing toward edge and fog nodes require containerization and orchestration mechanisms; however, the overhead introduced by the orchestration platform itself can reduce the benefit of distributed service placement and is particularly important for resource-constrained infrastructure. 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. Methods. A review and systematization of current microservice approaches to V2X, edge, and fog computing were carried out. K3s and K3s + KubeEdge configurations were experimentally compared on the same cloud VPS with unchanged hardware resources, software environment, and five workload profiles from idle to stress. Each profile was executed three times and the obtained results were averaged. CPU utilization, RAM consumption, network traffic, request counts, and the 95th and 99th latency percentiles were measured. Results . Adding KubeEdge increased RAM consumption by approximately 95–105 MB, or 6–8 % relative to K3s. Differences in CPU utilization, network traffic, and latency were minor; the increase in p95/p99 under high load occurred in both configurations and was primarily associated with node saturation. Novelty. The study separately evaluates the platform overhead of KubeEdge while keeping the V2X-oriented application workload unchanged. Practical significance . The obtained baseline can be used in further experiments to compare fixed and adaptive microservice placement in a distributed cloud–edge environment and to distinguish the application-level effect of balancing algorithms from orchestration overhead.

Performance of REST and gRPC in Microservices: Java Blocking vs. Python Non-Blocking I/O

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.

WebAssembly on the Cloud Continuum: A Multi-Architecture Evaluation on Kubernetes

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.

REST VS G RAPH QL: A PERFORMANCE COMPARISON UNDER VARYING LOAD AND QUERY COMPLEXITY