"Every time we open a list view in our internal management system, we wait several seconds. When we consulted our development vendor, they suggested upgrading the server due to increased traffic. But given the substantial cost, we aren't confident that will actually make it faster." We received this consultation from someone managing business systems at a manufacturing company. Assuming slowness equates to underpowered servers and upgrading specs rarely changes the perceived speed. This impasse is surprisingly common.
Recently, a technical investigation circulated widely among engineers detailing how an entire suite of database queries crossed the Pacific Ocean, even though both the server and database were hosted in Tokyo. While appearing entirely domestic on the surface, data was quietly routing abroad. For clients who commission software, this remains completely invisible. This article outlines what causes clients should investigate before reflexively resorting to server upgrades.
Two types of sluggishness: heavy processing versus physical distance
You can narrow down system performance issues by dividing them into two categories. The first is heavy processing. This happens when calculating massive datasets or executing inefficient queries takes significant time inside the server. The second is distance (latency). Even if the processing itself is instantaneous, data repeatedly travels back and forth between users, servers, and databases, accumulating wait times with each long round trip.
The advice that upgrading servers will improve performance applies only to heavy processing. When distance is the root cause, no amount of server scaling will reduce latency. If the physical route is long, driving a faster car will not shorten the mileage. Spending money on upgrades while confusing these two issues inevitably leads to high expenses with no noticeable improvement.
Why domestic setups end up crossing oceans
Even when servers and databases are intended to reside in Japan, traffic can inadvertently route abroad. Counterintuitive as it seems, this frequently happens for several reasons.
- Default service configurations point abroad: Cloud and database services often default to US regions unless explicitly configured otherwise. Systems built with domestic hosting in mind may leave certain components abroad unnoticed.
- Intermediary external services are hosted overseas: Relying on third-party services for authentication, payments, notifications, or mapping sends outbound queries to overseas servers on every execution.
- Routing mechanisms are misconfigured: Routing rules intended to direct traffic to the nearest node may malfunction, redirecting domestic users to distant international endpoints.
The impact of distance cannot be ignored. While intra-region communication is minimal, crossing regions roughly doubles round-trip latency, and routes routing from Japan through the US can easily add hundreds of milliseconds per call. When a single page load triggers dozens of these round trips, the cumulative effect results in several seconds of waiting.
Three questions clients should ask
Pinpointing root causes requires specialized skills, but clients can still guide investigations by asking development and maintenance partners the right questions. Before approving an upgrade quote, confirm the following:
| Question | What it verifies |
|---|---|
| In which regions are the servers, databases, and third-party services hosted? | Whether unexpected overseas regions have been introduced. |
| Have you isolated whether the bottleneck is processing or round-trip latency? | Whether an upgrade will actually address the underlying issue. |
| How many back-and-forth requests occur behind a single screen render? | Whether excessive round trips are compounding distance penalties. |
The core question is: "Before proposing an upgrade, did you determine whether the issue is heavy processing or network distance?" When vendors suggest upgrading servers without diagnostic breakdown, clients are fully justified in asking for evidence. Responsible developers benchmark where time is spent before proposing solutions. Upgrading without measurement is equivalent to paying for guesswork. The principle of starting from measurement to accelerate CI and builds is also explored in our article on speeding up Docker builds.
Measuring before upgrading prevents wasted spend
In the case of the aforementioned manufacturing client, we paused the server upgrade order and first measured execution times down to the millisecond. We discovered that most of the delay came not from server workload, but from repeated round trips to an overseas notification service triggered on every page view. It was a problem server upgrades could never fix. By batching requests to reduce frequency and moving domestic workflows closer to local infrastructure, perceived speed improved significantly without any server upgrade costs.
When a system runs slow, scaling servers seems like the most obvious remedy, but if distance is the culprit, the entire investment is wasted. Architectural issues like relying on overseas regions or excessive round trips to third-party services also warrant scrutiny from a business continuity standpoint, aligning closely with principles in designing for cloud resilience. Whether you need to uncover why a commissioned system is slow, evaluate whether an upgrade quote is justified with third-party review, or isolate bottlenecks through measurement, feel free to contact GleamHub for custom development and systems consulting. Rather than defaulting to upgrades, we work with you to identify high-impact remedies backed by metrics.
