Research
Cloud Computing & Distributed Systems
A middleware approach to reducing communication latency between distributed microservices, through topology-aware, node-affinity routing.
The master’s dissertation "A Middleware Approach to Microservices Latency Reduction" addresses one of the recurring bottlenecks of cloud-native architectures: as applications are decomposed into distributed microservices spread across regions, providers, and on-premises infrastructure, service-to-service communication becomes a critical source of latency, inter-regional traffic, and routing complexity. Building on a literature review of cloud and distributed computing, microservices architectures, and performance evaluation, the work proposes a lightweight, portable, and vendor-independent routing middleware designed to sit between clients and internal microservices.
The proposed middleware performs topology-aware routing: it resolves the hostname of the node handling a request and forwards the entire microservice pipeline to that same node, preserving processing affinity and avoiding unnecessary inter-node and inter-regional communication. The solution was implemented and evaluated in a Docker Swarm environment deployed across Amazon Web Services, Microsoft Azure, and an on-premises cluster, comparing scenarios with and without the middleware under different load profiles. The results show consistent latency reductions across all three environments, positioning the middleware as a lightweight alternative to traditional API Gateways and Service Meshes.

- Program
- M.Sc. in Computer Science & Engineering
- Institution
- Universidade da Beira Interior (UBI), Covilhã, Portugal
- Research Line
- Middleware, Cloud & Distributed Systems — sins-lab / NAS-CV, Instituto de Telecomunicações
- Advisor
- Prof. Dr. Tiago Miguel Carrola Simões
- Status
- Defended — Covilhã, July 2026
Experiment Results
Comparative latency results collected from the experimental environment described in the dissertation — each scenario runs 5 rounds of a fixed load profile with and without the middleware router, averaged below.
Consolidated performance results — 25 users (180 sec)
Average of 5 test rounds
| Metric | With Router | Without Router | Δ / Performance |
|---|---|---|---|
| avg | 433.10 ms | 649.56 ms | ▲ +33.32% |
| min | 167.73 ms | 238.01 ms | ▲ +29.53% |
| med | 335.87 ms | 559.12 ms | ▲ +39.93% |
| max | 2290.35 ms | 2757.47 ms | ▲ +16.94% |
| p(90) | 840.81 ms | 1096.84 ms | ▲ +23.34% |
| p(95) | 1062.79 ms | 1308.96 ms | ▲ +18.81% |
| Total Requests (avg) | 4,325.4 | 4,225.6 | |
| Data Received (avg) | 1.66 MB | 1.08 MB | |
| Data Sent (avg) | 940.32 MB | 918.62 MB |
Comparison Between AWS, Azure, and On-Premises
In the scenarios with middleware, AWS and Azure showed consistent multi-region cloud behavior, with average latencies in the range of hundreds of milliseconds. The on-premises environment showed significantly lower latencies under a load of 25 users/s, but greater sensitivity in 50 users/s scenarios with longer-running tests.
Table 4.21 presents important observations regarding the performance of the tests executed in the three environments.
Table 4.21 — Comparative synthesis by environment
| Criterion | AWS | Azure | On-Premise |
|---|---|---|---|
| Average latency with middleware | Intermediate and stable range | Intermediate-to-high range, with strong relative gain | Very low at 25 users/s; high in prolonged 50 users/s tests |
| Percentage gain with middleware | Consistent improvement (approx. 33% to 49%) | Higher improvement (approx. 46% to 56%) | Variable improvement (approx. 14% to 47%) |
| Stability under sustained load | High | Good, with greater variation than AWS | Good under low load, sensitive under high load |
| Observed practical scalability | Balance between latency and throughput | Good relative gain, with higher absolute latency cost | Limited by the physical resources of the local cluster |
Conclusions
Across AWS, Azure, and an on-premises cluster, the middleware cut communication latency by roughly 14% to 56% versus the baseline, with throughput held steady or improved — gains driven purely by application-level routing, with no infrastructure changes required. The largest improvements showed up in the cloud environments, where inter-node hops are costliest, positioning topology-aware routing as a lightweight complement to traditional scaling and orchestration strategies rather than a replacement for them.
Future Work
- Support for additional orchestration platforms beyond Docker Swarm
- Dynamic topology discovery and adaptive routing based on live network conditions
- Distributed tracing and runtime-metric-driven route optimization
- Larger-scale evaluations across more regions and cloud providers
- ML-based prediction of communication patterns for proactive routing