Too Many Microservices? How We Consolidated 30+ Services Into 5

A fintech platform we took over had more than 30 microservices, a separate backend-for-frontend (BFF) layer for each of them, and a micro-frontend user interface. A single release needed up to 20 coordinated deployments and took one to two days. After consolidating into a handful of larger services, the same release takes under 20 minutes.

This is how we did it, and how to tell whether your own architecture has gone the same way.

How do you know you have too many microservices?

• A small feature needs code changes in several services at once
• A release means coordinating many deployments by hand
• Tracing one piece of data from database to screen means opening half a dozen repositories
• When something breaks, finding the failing service takes longer than fixing it
• New engineers need weeks before they can safely change anything

The platform we inherited had all five.

Resume-driven architecture

Microservices solve a real problem: many teams working on one product without blocking each other. The pattern was designed for organisations with hundreds or thousands of engineers. A scaling fintech with one product team does not have that problem, but it still pays the full cost of the pattern.

We call this resume-driven architecture: choosing a setup because it looks impressive, not because the business needs it.

What we found

• 30+ backend microservices, each with its own BFF connecting it to the interface and its own database
• A micro-frontend: dozens of mini-apps stitched together instead of one front end
• Up to 20 coordinated deployments per release, taking one to two days
• Fragile dependencies: every small change broke something somewhere else

The team spent more time keeping the infrastructure running than building the product.

How we consolidated the architecture

Peter Vidlička, our Co-Founder and Managing Director, drove the decision to simplify the platform rather than patch it. Arne De Herdt, our Software Architect, designed the target architecture.

1. One front end. We replaced the micro-frontend with a single application. A financial product has to feel like one fast, consistent product, not a set of joined-up mini-apps.
2. Services grouped by business domain. We audited the 30+ services and grouped the logic into 5 or 6 larger services, each owning one area of the business.
3. One security layer. Instead of a BFF per service, a single gateway now handles authentication and data protection. One front door means fewer security blind spots.
4. One database (the final step, in progress). Every microservice had its own database. We are now migrating that swarm of small databases into a single one.

Results

	Before	After
Backend services	30+	5 to 6
Deployments per release	Up to 20	5 at most
Time per release	1 to 2 days	Under 20 minutes
Onboarding a new engineer	Weeks	Days

The consolidation is nearly complete; merging the per-service databases into one is the last step.

When should you consolidate microservices?

Consider consolidating when:

1. Most features touch more than one service
2. One team owns all the services anyway
3. Releases need manual coordination
4. Services share a database or call each other in long chains
5. Infrastructure work takes more time than product work

Keep separate services where scaling, security or team ownership really differ.

FAQ

Are microservices bad? No. They suit large organisations with many independent teams. They hurt when a small team has to carry their overhead.

What is a macroservice? A larger service that owns one whole business domain, such as payments or onboarding, instead of a single function.

Are micro-frontends worth it? Rarely for one product team. They add build and runtime complexity, and users notice the seams.

If your team spends days on releases, talk to us about an architecture review.