Skip to content

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.

Reges Hengen
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

MetricWith RouterWithout RouterΔ / Performance
avg433.10 ms649.56 ms▲ +33.32%
min167.73 ms238.01 ms▲ +29.53%
med335.87 ms559.12 ms▲ +39.93%
max2290.35 ms2757.47 ms▲ +16.94%
p(90)840.81 ms1096.84 ms▲ +23.34%
p(95)1062.79 ms1308.96 ms▲ +18.81%
Total Requests (avg)4,325.44,225.6
Data Received (avg)1.66 MB1.08 MB
Data Sent (avg)940.32 MB918.62 MB
With MiddlewareWithout Middleware
05001k1.5kavgmedp(90)p(95)

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

CriterionAWSAzureOn-Premise
Average latency with middlewareIntermediate and stable rangeIntermediate-to-high range, with strong relative gainVery low at 25 users/s; high in prolonged 50 users/s tests
Percentage gain with middlewareConsistent improvement (approx. 33% to 49%)Higher improvement (approx. 46% to 56%)Variable improvement (approx. 14% to 47%)
Stability under sustained loadHighGood, with greater variation than AWSGood under low load, sensitive under high load
Observed practical scalabilityBalance between latency and throughputGood relative gain, with higher absolute latency costLimited 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