For over a decade, microservices have been widely promoted as the architectural evolution that would solve the scalability and agility problems of monolithic systems. Inspired by the successes of tech giants like Netflix and Amazon, many organizations began decomposing their applications into small, independently deployable services. Microservices offered a promise: faster deployments, language and technology flexibility, and resilience through service isolation.
The Downsides of Microservices
Microservices inherently introduce distributed system challenges. A single user request might now span multiple services, creating cascading dependencies that are harder to debug, monitor, and secure. What used to be a simple function call becomes an HTTP request with potential network latency, serialization issues, and failure points. Managing distributed transactions, maintaining data consistency across services, and handling eventual consistency patterns adds significant development overhead.
Moreover, microservices often demand advanced infrastructure capabilities. Continuous integration pipelines, container orchestration platforms like Kubernetes, service discovery tools, distributed logging, and tracing frameworks become essential just to keep things running. For organizations without a mature DevOps culture or the engineering capacity to support this level of complexity, microservices can slow teams down rather than speed them up.
Real-World Cases of Inverse Migration
Several prominent companies have publicly shared their decision to consolidate microservices back into a monolithic or modular monolithic architecture.
One of the most cited cases is Amazon Prime Video. In a blog post published in 2023, their engineering team described how a distributed system that powered live video monitoring was becoming inefficient and expensive. By consolidating their microservices into a single monolith, they reduced their infrastructure cost by over 90% and improved performance dramatically. As the Prime Video post by Marcin Kolny puts it: “We realized that a distributed approach wasn’t bringing a lot of benefits in our specific use case, so we packed all of the components into a single process.” [1]
Similarly, Segment, now part of Twilio, found that their microservice architecture became difficult to manage at scale. Engineering productivity declined, with teams spending more time debugging inter-service communication issues than delivering features. Their solution was to rebuild core functionality into a monolithic service, which brought back predictability and improved performance [2].
Even Basecamp, the creators of Ruby on Rails, have consistently argued that monoliths are a better fit for most companies. In their book It Doesn’t Have to Be Crazy at Work, they describe how a single, well-organized codebase allows for more effective collaboration and simpler deployment. [3]
Should You Migrate to Microservices?
| Consideration | Microservices Are a Good Fit When... | Stick with or Revert to a Monolith When... |
|---|---|---|
| Team Structure | You have multiple, autonomous teams, each owning distinct domains. | Your team is small or not yet organized around clear domain ownership. |
| Deployment Needs | Services must be deployed independently, with different scaling and release cadences. | Coordinated deployment is acceptable or preferred for simplicity. |
| System Complexity | The system is too large or evolving too quickly to manage as a single codebase. | The system is manageable as one codebase and doesn’t suffer from scaling bottlenecks. |
| Performance and Scalability | You need to scale parts of the system independently (e.g., high-traffic components). | Your monolith performs well and scaling needs are not critical. |
| Tech Stack Diversity | Different services benefit from different languages, frameworks, or databases. | A uniform tech stack suffices for your needs and is easier to maintain. |
| Operational Maturity | Your org has mature DevOps, CI/CD, observability, and monitoring practices. | You lack the resources or infrastructure to manage distributed systems effectively. |
| Development Speed and Overhead | You’re struggling with coordination across a bloated monolith and domain boundaries are clear. | Microservices introduce more overhead than benefit; glue code and boilerplate slow you down. |
| Problem Nature | You're solving problems that clearly benefit from decomposition and asynchronous communication. | The problems are best tackled in a tightly integrated environment with shared context. |
Conclusion
Microservices are not a destination, they’re a tool. The right architecture depends on factors like team size, system complexity, domain boundaries, and operational maturity. In many cases, monoliths offer better performance, simpler debugging, and lower operational cost, particularly when components are tightly coupled or share heavy data dependencies. Reducing unnecessary data movement between services can yield significant efficiency gains, and scaling strategies should always be driven by the specific needs of your workload, not by trends. Most importantly, architectural change should be iterative, optimising bottlenecks and simplifying critical paths often brings more value than a full-scale redesign.
References
[1] https://www.mirantis.com/blog/what-to-think-about-when-you-think-about-microservices/
