When to Merge Microservices Back into a Monolith: Balancing Technical and Organizational Concerns

I am not anti‑microservice; I only merge services back into a monolith when it yields a "just‑right" sized system that reduces friction for my team, avoiding the cost of refactoring old code.

Microservices were originally introduced to solve two kinds of problems: technical issues that overload infrastructure (e.g., CPU‑intensive image processing) and people problems caused by too many engineers competing for the same deployment pipeline.

At InVision, the early microservices were created mainly to solve the people problem: as the engineering team grew from three to dozens, everyone was fighting for the same deployment queue, causing rollbacks and coordination friction.

Conway's Law states that a system's design mirrors the communication structure of the organization that builds it. When service boundaries align well with team boundaries, teams can ship more reliably; when they misalign, the benefits turn into liabilities.

Over time, InVision ended up with a legacy platform and a modern platform, and my "Rainbow" team transitioned to the legacy side, inheriting many services, languages, databases, and dashboards, which increased operational burden.

Consequently, we are now re‑evaluating service boundaries to match current team structures, often merging services back into the monolith to achieve a more manageable, appropriately sized system.

The term "micro" is misleading; services should be sized appropriately for their responsibilities, team skills, ROI, and operational costs, not merely made smaller for its own sake.

Independent scalability is often cited as a benefit of microservices, but unless a function is truly CPU/IO bound, separate scaling may add unnecessary complexity without real performance gains.

In hindsight, focusing on CPU‑bound functions (image processing, thumbnail generation, PDF handling, etc.) and building pure, loosely‑coupled services for them would have solved many of the original problems.

Overall, microservices are a technical tool to address organizational challenges, and their usefulness depends on aligning service boundaries with team boundaries and real technical constraints.