We Moved Back to a Monolith (And It Was the Right Call)

A client came to us with a system that had been architected as 12 microservices from day one. The team was 6 engineers. They were spending more time debugging distributed system issues than building features. Deployments required coordinating across multiple services. A single API request touched 4-5 services on average.

The microservices had been introduced because 'that's what you do at scale.' But the system had 500 daily active users. The engineering team was drowning in operational complexity that provided zero business value.

This is a pattern we see often: microservices adopted as a default architectural choice rather than a deliberate response to specific scaling challenges.

We didn't just merge everything into one big ball of mud. We designed a modular monolith — a single deployable unit with clear internal boundaries. Each former microservice became a module with its own directory, data access layer, and public API (exported functions, not HTTP endpoints).

The migration happened over 6 weeks. We started by mapping all inter-service communication, identifying the dependency graph, and planning a merge order that minimised risk. Services with the most inbound dependencies were migrated first.

We kept the database schemas separate initially — each module owned its tables. This preserved data isolation while eliminating network calls. Over time, we consolidated some schemas where it made sense, but the module boundaries remained clear.

The numbers speak for themselves. Average API response time dropped from 280ms to 45ms — eliminating inter-service network calls was the biggest win. Deployment time went from 45 minutes (coordinating 12 services) to 3 minutes (one service, one pipeline).

Developer productivity improved dramatically. New engineers could understand the entire system in days instead of weeks. Debugging went from 'which service is the problem?' to straightforward stack traces. The team went from shipping one feature per sprint to three.

Infrastructure costs dropped 40%. Twelve separate services meant twelve sets of load balancers, container instances, and monitoring stacks. One modular monolith needs one of each.

We're not anti-microservices. They're the right choice when you have genuinely independent teams that need to deploy independently, when different parts of your system have fundamentally different scaling requirements, or when you need technology diversity (one service in Python for ML, another in Go for performance).

The key question is: do the benefits of independent deployment and scaling outweigh the costs of distributed system complexity? For a team of 6 with 500 users, the answer was clearly no. For a team of 60 with millions of users, it might be yes.

Start with a modular monolith. Extract services only when you have a specific, measurable reason to do so. You can always split a well-structured monolith into services later. It's much harder to merge poorly-bounded services into a coherent whole.