For a decade, microservices were the only acceptable architecture for serious software. Splitting applications into dozens of independently deployed services was presented as the path to scalability and team autonomy. But in recent years, prominent companies have publicly moved back to monoliths — and the engineering community is paying attention. Amazon Prime Video, Shopify, and others have shared stories of cutting costs and complexity by consolidating services. What is driving this shift?
The Hidden Costs of Microservices
Microservices solve a real problem: they let large engineering organizations work independently on different parts of a product. Team A can deploy their service without coordinating with Team B. Each service has its own codebase, its own test suite, and its own deployment pipeline. For companies with hundreds of engineers, this independence is essential.
But microservices also introduce significant overhead. Every service needs its own CI/CD pipeline, monitoring, logging, and alerting. Inter-service communication happens over the network, which adds latency, requires serialization and deserialization, and introduces failure modes that do not exist in a monolith. A function call that takes microseconds within a process becomes a network request that takes milliseconds — and can fail, timeout, or return unexpected data.
Distributed tracing, service meshes, circuit breakers, retry policies, and API version management are all infrastructure that exists solely to manage the complexity that microservices create. For a team of five to twenty engineers, this overhead often exceeds the organizational benefits. The team is small enough to coordinate deployments, and the additional infrastructure slows down rather than speeds up development.
What a Modern Monolith Looks Like
When engineers hear "monolith," they often picture a tangled codebase with no internal structure. That is a Big Ball of Mud, not a monolith. A well-structured monolith uses clear module boundaries, separate packages or namespaces for each domain area, and strict dependency rules enforced through architecture tests.
The key principle is the Modular Monolith. Each module owns its data and exposes a clean interface to other modules. Modules cannot reach into each other's databases or internal classes. They communicate through defined APIs — the same interfaces you would use in microservices, but through in-process function calls instead of network requests.
This structure gives you most of the organizational benefits of microservices — clear ownership, independent development, testable boundaries — without the operational overhead of distributed systems. And if you later need to extract a module into a separate service, the clean interface makes the migration straightforward because the boundary is already defined.
Performance and Operational Advantages
A monolith deployed as a single process eliminates network latency between components. A request that touches three domain areas makes three function calls instead of three HTTP round trips. For read-heavy workloads, this saves hundreds of milliseconds per request. For write-heavy workloads that require transactional consistency across domains, a monolith can use database transactions rather than implementing distributed sagas.
Operationally, a monolith is simpler to deploy, monitor, and debug. One deployment pipeline, one application log, one set of metrics. When something goes wrong, the stack trace shows the full call chain instead of requiring you to correlate logs across multiple services using trace IDs. For startups and small teams, this operational simplicity means more time building features and less time maintaining infrastructure.
Scaling a monolith is also simpler than it is often portrayed. Horizontal scaling — running multiple instances behind a load balancer — works for most web applications. If a specific component needs more resources, you can scale the entire application and rely on the load balancer to distribute traffic. Yes, this is less efficient than scaling individual services independently, but the simplicity often outweighs the cost of running slightly more compute.
When Microservices Are Still the Right Choice
Microservices remain the right architecture when your organization is large enough that team coordination becomes a bottleneck. If you have fifty engineers working on the same product, independent deployment becomes important enough to justify the distributed systems overhead. Similarly, if different components have fundamentally different scaling requirements — a real-time chat service running alongside a batch reporting engine — separating them makes sense.
The key insight behind the monolith resurgence is not that microservices are bad — it is that architecture decisions should be driven by organizational needs and workload characteristics, not industry trends. Start with the simplest architecture that meets your requirements. Add complexity only when you have specific problems that demand it.
For most SaaS products built by teams of five to thirty engineers, a modular monolith deployed as a single application provides better developer productivity, lower operational costs, and faster iteration than a microservices architecture. The monolith is not a step backward — it is a pragmatic choice that lets you focus on building your product instead of managing your infrastructure.