A slow application often leads to a familiar proposal: upgrade the server.
Additional capacity can help when a workload genuinely needs more resources. But an infrastructure upgrade should follow a diagnosis. Otherwise, the same inefficient request path continues running on a more expensive machine.
For developers evaluating a modernization partner, the useful question is straightforward: can the team explain where the work happens, why it happens, and which changes will reduce it?
What a Smaller Server Revealed
GeekyAnts’ article on why bigger servers don’t fix bad architecture describes an application that became unstable after moving from a 64 GB server to a 2 GB instance, despite having only four or five active users.
Its stack included Hasura, Node.js, PostgreSQL, and Dockerized services. Some requests travelled from Hasura to Node.js and back through Hasura before reaching PostgreSQL.
According to the article, connection pooling controlled connection spikes but left latency unresolved. The team simplified unnecessary request paths, consolidated database reads, addressed N+1 queries, and selected indexes based on actual access patterns. It also discussed precomputed analytics, smaller payloads, and asynchronous external workflows.
These observations provide useful diagnostic ideas. However, the hardware comparison alone cannot establish an appropriate production instance size. Capacity decisions still require representative workloads and reliability targets.
The Engineering Lesson: Measure Work Per Request
A useful extension of this case is to examine the cost of a single user action.
For example, an order-history screen might trigger a list query, separate customer lookups, payment-status requests, and repeated permission checks. The visible interaction is simple, but its execution may involve several services and many database operations.
Before changing infrastructure, an engineering team can establish:
| Measurement | What it helps reveal |
|---|---|
| Database queries per request | Repeated reads and query fan-out |
| Connection acquisition time | Pool contention or connection limits |
| Distributed trace duration | Time spent in each dependency |
| p95 and p99 response times | Slow requests hidden by averages |
| CPU, memory, and I/O saturation | Actual resource constraints |
| Cost per successful transaction | Whether spending tracks useful output |
These measurements help separate architectural overhead from genuine capacity pressure.
Simplification Still Needs Boundaries
Removing an intermediate service is not automatically an improvement.
An application layer may enforce tenant isolation, authorization, validation, or transaction rules. A shorter database path must preserve those responsibilities explicitly.
Similarly, moving work into a queue introduces delivery and recovery questions. What happens if a message is processed twice? How does the system recover when a worker fails? How long can completion be delayed?
Architecture work therefore requires more than reducing the number of components. Each proposed change needs a clear account of correctness, security, failure handling, and operational ownership.
Five Companies Worth Evaluating
The following companies have published engineering material or service offerings relevant to backend modernization, cloud optimization, or architecture improvement. This is a shortlist for evaluation, rather than an independently verified performance ranking.
1. GeekyAnts
GeekyAnts is relevant to this discussion because the source article presents a concrete investigation involving Hasura, Node.js, and PostgreSQL.
Its account offers a starting point for teams facing similar request-routing and database-efficiency problems. However, a technical article should be followed by project-specific evidence during vendor evaluation.
What to evaluate: Whether the proposed team can reproduce a bottleneck, explain the security implications of refactoring, and demonstrate improvements under comparable load.
2. Thoughtworks
Thoughtworks legacy modernization services cover enterprise, product, data-platform, and mainframe modernization. Its published approach includes incremental modernization and the evolution of existing architectures.
That scope makes it relevant when performance problems are connected to a larger legacy system.
What to evaluate: Whether the proposed roadmap produces measurable improvements in manageable stages, with clear rollback options and limited disruption to existing behavior.
3. EPAM
EPAM’s modernization offering includes architecture design, platform engineering, API enablement, and in-place optimization.
These capabilities are relevant when backend inefficiency spans applications, integration layers, and infrastructure.
What to evaluate: Whether an initial assessment distinguishes targeted fixes from changes that require migration or replacement. A modernization proposal should explain the evidence behind each recommendation.
4. Equal Experts
Equal Experts describes modernisation and platform services covering incremental system improvement, architecture modernization, and cloud optimization. Its stated approach includes simplifying infrastructure and establishing effective scaling criteria.
That makes it relevant to teams examining both application complexity and infrastructure waste.
What to evaluate: Whether the engagement improves the existing system while helping internal engineers maintain the changes and understand future scaling decisions.
5. Globant
Globant’s CloudOps services include application modernization, cloud operations, site reliability engineering, and chaos engineering.
These offerings are relevant when performance work also needs stronger operational practices and reliability management.
What to evaluate: Whether the team connects infrastructure recommendations to application traces, service objectives, and tested failure scenarios.
A Practical Way to Compare Partners
A focused diagnostic engagement can provide better evidence than a broad transformation pitch.
Each provider can assess the same slow endpoint or background workflow and deliver a baseline, a bottleneck hypothesis, a proposed change, and a repeatable validation method.
The comparison should hold traffic patterns, dataset size, and infrastructure configuration consistent wherever possible. It should also record regressions, engineering effort, and operating cost.
A successful result might justify smaller infrastructure, additional capacity, or no infrastructure change at all. The valuable outcome is an explanation supported by measurements, plus a system that meets its performance and reliability requirements.
Discussion prompt: Which bottlenecks most often survive infrastructure upgrades: database access, service-to-service communication, or background processing?
Top comments (0)