~1,000 requests per publish: finding the hidden cost
Context
The development backend ran on isolated feature clusters built with Docker and Kubernetes, with one cluster per developer. Each cluster had its own pod containing a translation cache populated from a cloud translation service. This was part of the same B2B2C platform described in the micro-frontend platform case study.
How I found the problem
The issue started with a number in the cloud translation service dashboard: the projected cost for the month was much higher than I expected. That raised a simple question — what was generating so many paid requests?
I traced the publishing flow through the feature clusters and found that a single translation publish was being processed independently by every pod. The same data was therefore being fetched repeatedly across the development environments instead of being shared.
What was causing the requests
The platform served 28 applications in four languages. The cache-building code had two separate problems that made the situation worse:
- it contained unnecessary loops that caused the same work to be repeated,
- it fetched all translations after every publish instead of requesting only the translations that had actually changed.
Combined with a separate cache in every feature cluster, those inefficiencies multiplied into a large number of paid API calls.
What I did
- Traced the translation publish flow and followed the requests across clusters, pods, applications and languages.
- Identified the unnecessary loops and the full-cache fetch in the code responsible for building the translation cache.
- Reported the findings to management and explained where the unnecessary requests were coming from.
The fix
The cache implementation itself belonged to another team's codebase, so they implemented the final change based on my diagnosis.
The new approach removed the unnecessary loops, fetched only the translations that had changed and populated a shared cache instead of repeating the same work independently in every feature cluster.
Measurable impact
A single publish went from roughly 1,000 repeated requests to one shared fetch, plus only the requests needed for the applications whose translations had actually changed.
- ~1,000 → 1 + changed applications requests per publish
- −99.9% paid API calls
The important change was not just a lower number of requests. The same translation data stopped being downloaded and processed independently by every development cluster.
What this case shows
The frontend was not the only place to look for the problem. A cost visible in a cloud dashboard led to an investigation through the application, API calls, cache implementation and Kubernetes environment.
This is the kind of problem I look for during a frontend performance audit: inefficiencies that are easy to miss in isolation but become expensive when multiplied by the architecture around them.
The work was part of the same larger platform described in the micro-frontend platform case study, and it is closely related to my work on micro-frontend architecture.
Stack
.NET, Kubernetes, Docker, i18n, cloud translation API.