Walked back microservices decomposition without rewriting twelve services
A logistics company had broken up their Java monolith into 37 services and was struggling with distributed transaction complexity. We helped them merge twelve services back without touching the underlying business logic.
A $900M-revenue logistics company had spent two years breaking up their core Java monolith into microservices. By June 2025 they had 37 services in production, and the architecture team had concluded — privately at first, then publicly — that some of the boundaries were wrong. Twelve of the services were either too small to justify their operational overhead or were creating distributed transaction patterns that the team was struggling to debug.
Walking back a microservices decomposition is a different engineering problem from doing one. The trap is rewriting business logic during the merge, which compounds risk. We proposed a strict rule: every service merge would preserve the existing service's code structure inside a Spring Boot module of the destination service, with no business logic refactoring during consolidation. Logic cleanups could happen later, separately.
The eleven-week engagement merged twelve services into five host services. Each merge was a feature-flagged cutover: deploy the consolidated service, route 5% of traffic for a week, ramp to 100% over five days, decommission the original service after a two-week soak period. The team did three merges in parallel at peak, with our engineers handling the trickier transactional services and theirs handling the simpler stateless ones.
Operational metrics improved across the board after consolidation: deploy time dropped 30% (fewer pipelines to coordinate), distributed tracing complexity halved, and the team's on-call burden — which had been the original motivation — became sustainable again. The architecture team has paused further consolidation to observe the new shape; we expect another 3-5 services to merge over the next year.