The Hidden Cost of Overengineering Microservices: How We Cut Cloud Costs by 82%

When microservices are overused, complexity and costs skyrocket. Here’s how we consolidated 25 services into 5 – simplifying architecture and slashing cloud spend without sacrificing stability.

It’s hard to predict exactly how microservice architecture will evolve, what pros and cons will surface, and what long-term impact it will have. Microservices can offer significant benefits — like scalability, independent deployments, and improved fault isolation — but they also introduce hidden challenges, such as increased complexity, communication overhead, and maintenance costs.

While this architectural approach brings flexibility in managing systems, prioritizing critical components, and streamlining release and testing processes, it won’t magically fix everything — architecture still needs to make sense. Applying the wrong architecture can create more problems than it solves. Poorly designed microservices may lead to inefficiencies, tight coupling in unexpected places, and operational overhead that outweighs their advantages.

Entry point: reclaiming architectural simplicity

The project we took on was an example of microservice architecture applied without tailoring it to the actual shape and needs of the system. Relatively small and simple applications were over-decoupled. Not only were different modules and domains split into separate services, but even individual layers — such as REST API, services containing business logic, and database repositories — were extracted into separate microservices. This is a classic case of solving a simple problem with a complex tool, without adapting to the context.

Our mission was to refactor the system — not just at the code level, but at the architectural level — with a primary focus on reducing the long-term maintenance costs. To achieve this, we’ve decided to retain the microservice approach, but with a more pragmatic level of granularity. Instead of 25 microservices, we consolidated the system into just 5 thoughtfully grouped services, reduced cache instances from 3 to 1 and migrated 10 databases into 5.

Consulting the system

Before making any decisions, we conducted a thorough audit of the system’s architecture, application performance, efficiency, and overall cost. Looking at the raw architectural diagram alone is rarely enough — we wanted to observe the system in action and pay close attention to key metrics. This live analysis provided critical insights into configuring the new applications to better meet the system’s original requirements while reducing operational costs.

Cloud Provider access

To truly understand a system’s architecture, it’s essential to have access to the cloud provider’s environment — with a wide set of permissions. This level of visibility pays off significantly. The more detailed your understanding at this stage, the more opportunities you uncover for optimization and cost savings during consolidation.

Monitoring tools access

Most systems include monitoring tools to track their health and performance. These insights help identify which metrics are most critical for the system. Depending on the use case, the key factor might be computing power, memory usage, instance count, or concurrency. In our case, we discovered that some microservices were being unnecessarily autoscaled. CPU usage was rising — not due to a lack of resources, but because of accumulating requests in the next microservices in the chain that performed heavy calculations and interacted with external APIs. Understanding these patterns enabled us to make informed decisions about application container configurations and auto scaling strategies.

Refactoring, consolidating, and optimizing cloud architecture

We successfully consolidated 25 microservices into 5 independent, self-sufficient applications, each backed by one of 5 standardized databases — down from a previously fragmented set of 10 and a single cache instance instead of 3. Throughout this transformation, we stick to a core refactoring principle: system inputs and outputs must remain unchanged. Internally, however, architecture and data flow were redesigned to improve efficiency and maintainability.

We carefully defined domain boundaries to determine which services could be merged. In most cases, previously separated layers — REST proxies, service logic, and repositories — were brought together in an unified application within a single domain. Some applications required database migrations, resulting in consolidated databases structured into multiple schemas to preserve legacy boundaries.

Although we estimated resource requirements for the new services, production behavior can be unpredictable — especially when pre-launch workload testing isn’t possible. To stay safe, we provisioned a performance buffer to handle unexpected spikes.

While cost reduction was our main goal, we knew we were dealing with customer-facing apps where stability and user experience come first. That’s why we took a safe and thoughtful approach — focusing on smart consolidation and optimization without risking reliability. Our goal wasn’t just to cut costs, but to do it in a way that also improved the system without impacting end-users.

Challenges and risks of architecture refactoring

Limited business domain knowledge

It’s a tough challenge when you’re working with applications and domains without deep insight into the business logic. On one hand, it wasn’t strictly required since we were operating on a higher architectural level. But every time we needed to test and fix issues after consolidation, we had to investigate from scratch — often without clear guidance or domain expertise.

Lack of testing opportunities​

In maintenance-phase projects, it’s common that dedicated QA support or testers with deep system knowledge aren’t available — which is totally understandable. At this point, we often rely on the work done by previous developers: verifying what types of tests exist, how well they cover the code and business logic, and how effective they are at catching real issues.

Parallel consolidation limitations

The original system’s granularity made it difficult for more than one developer to work on consolidating a single microservice simultaneously. Typically, each domain was handled by one developer, but in some cases, having multiple people working together could have helped prevent issues during such a complex process.

Backward compatibility​

Every consolidated application had to be 100% backward-compatible with the pre-consolidation microservices to allow for rollbacks if needed. That meant we couldn’t introduce any breaking changes during the transition — adding extra pressure to get things right the first time.

Distributed configuration​

The old system’s over-granular design scattered configuration across multiple services and a config server. Rebuilding that into a unified configuration required careful investigation to locate, align, and centralize everything in one application.

End-user impact​

Since the system was customer-facing, any bug or functionality gap after consolidation could directly affect users. This raised the stakes for every change and reinforced the need for a cautious, thoughtful rollout.

Architectural refactoring comes with risks and understanding them upfront is key to delivering both system reliability and cost efficiency.

What we gained: lower costs, higher reliability, and a sustainable system

Cloud cost reduction

After consolidation, overall cloud infrastructure costs were reduced by 82%. This was a direct result of architectural refactoring, microservices reduction, and more efficient resource usage.

Monitoring tool efficiency

The new architecture also lowered the load on external monitoring tools, leading up to 70% drop in related costs.

Indirect cost savings

While we didn’t have full access to some billing metrics, we know that many tools charge based on factors like request volume, microservice count and internal traffic. Simplifying the core of the system brought savings across these areas too.

Simplified maintenance

Shrinking from 25 microservices to 5 dramatically reduced the effort required for feature development, domain-specific releases, and CI/CD pipeline management. Once we removed the facade of complexity, it became clear the system wasn’t as complicated as it seemed. Onboarding new developers is now much faster and easier — which also opens the door to rethinking how many engineers are truly needed for ongoing support.

Zero downtime deployment

Since we were working with a customer-facing system, minimizing downtime for each release was critical. By consolidating functionality into 5 clearly defined, domain scoped applications, we made it possible to achieve zero downtime deployments in production.

Reduced complexity

Consolidation clarified how the system works and gave developers a wider view of its components. With cohesive domains and logic housed in fewer applications, it’s now easier to follow business flows, implement efficient solutions, debug issues, and write effective tests.

—

Every decision made at a given moment usually feels like the right one — and often it is. But if something remains important over time, it’s worth revisiting that decision in light of new context and evolving circumstances. As our case clearly shows, taking the time to reevaluate can truly pay off — both literally and figuratively.