Based on a real production issue (simplified). It shows why doing small performance tests — especially at the component level (like integration tests) — helps find hidden bottlenecks early and avoids costly problems in large systems.
This repository provides a minimal reproducible environment that shows typical performance problems in a distributed architecture (Gateway → Authentication → Business Logic).
The scenario is based on a real production issue, but it was fully cleaned, simplified, and contains no confidential data.
This project helps developers better understand:
- why fine-grained performance tests – from simple benchmarking to component or integration tests– are as important as system-wide performance tests.
- how to build reproducible test environments to find performance issues early.
The project simulates a simple but realistic service chain:
- gateway-for-test – API Gateway
- auth-service-for-test – Authentication Service
- service-for-test – Business Service
All services are fully containerized and can run alone or together with Docker.
In the branches that contain the full example code (for example 0.0.1, 0.0.2, etc.), there is a
docker-compose.yml file inside the resources/ folder. This file allows you to start the whole test environment
quickly.
The main branch contains only the project description and no runnable code.
A simple architecture diagram:
Different branches show different versions of the system:
- Branch 0.0.1 contains a planned performance bottleneck. The problem comes from using a RestTemplate with a synchronous HttpClient inside WebFlux, which creates high latency under load.
- Branch 0.0.2 fixes the bottleneck from 0.0.1 and includes an evaluation of the improvements. During testing, it also shows that Logback creates noticeable performance cost while writing logs.
- Branch 0.0.3 fixes and analyses the issues found in 0.0.2. It also includes a solution and details for the blocking issue during UUID generation.
Each branch contains more detailed explanations, test methods, and results.
While working on this project, it became clear that performance testing does not try to find one single “correct” number. In real systems, the results can change a lot depending on the environment — for example CPU power, network, container settings, or software versions.
From this experience, three important principles can be learned:
Even if a single service or component shows very good results in a benchmark, it does not mean the whole system will show the same performance.
Small tests are still very useful because they help to:
- find obvious mistakes early, before they become expensive and hard to reproduce
- save time and cost, because problems can be found before the system becomes complex
- give developers — especially those who build shared or reusable components — a good tool to check quality and stability
These tests cannot replace system-level tests, but they build the foundation for good performance analysis.
Test results can be very different in different environments. Even small changes — hardware, thread settings, network latency — can make a big difference.
For this reason, performance tests must be done several times and in realistic conditions.
In many systems, it is important to compare the value of code optimization with the cost of simply adding more nodes or scaling horizontally.
Improving performance on a full system can be expensive:
- building a 1:1 or scaled test environment
- creating or importing realistic test data
- running many test rounds
- spending a lot of time and team effort
It is important to remember:
👉 The goal is good enough performance, not maximum performance.
An optimization only makes sense if the benefit is bigger than the cost.
This project demonstrates this methodology:
The goal is not to reach a specific number, but to systematically find, analyze, and fix bottlenecks — and apply this thinking to real production systems.
In the project root directory, you can build all service images using the provided scripts:
gateway-for-test/resources/scripts/build-image.sh -d .
service-for-test/resources/scripts/build-image.sh -d .
auth-service-for-test/resources/scripts/build-image.sh -d .cd resources && \
docker-compose --compatibility -f docker-compose.yml upThe Gateway provides a simple test route. You can call it like this:
curl http://127.0.0.1:38071/service/helloFor more tests, you can also use external tools to create parallel or high-load requests. I use a lightweight tool like wrk, because it is good for simple and reproducible load tests.
More detailed examples and results can be found in the related branches (for example 0.0.1, 0.0.2).