Microservices have been the default recommendation in architecture discussions for years. Still, a well-structured monolith is the better choice for many organizations. The decision between these approaches is not about technical taste. It depends on team size, domain complexity, and operational maturity. When does migration actually make sense, and when is staying with the monolith the smarter move?
What Monoliths Do Well
A monolith is not an anti-pattern. For teams with fewer than 20 developers working on a clearly bounded domain, it brings real advantages: a single deployment artifact, one debugging context, no network latency between components. A rename applies everywhere instantly, and refactoring across module boundaries stays simple.
Shopify runs one of the largest Ruby on Rails monoliths in the world. Why? The architecture matches the organizational structure. As long as a team can oversee and deploy the entire codebase, splitting it into services mainly creates additional complexity.
Things get tricky when the monolith grows without anyone drawing internal boundaries. That is when technical debt piles up: long build times, fragile tests, deployment anxiety.
When Microservices Actually Help
Instead of asking “Are microservices better?”, the better question is: “Do they solve a problem we actually have today?” Three signals point toward a split:
When Team A wants to deploy weekly but has to wait for Team B’s bi-weekly sprint, the coupled codebase becomes a bottleneck. Separate services with their own pipelines fix that, provided the DevSecOps practices are in place.
Second signal: different scaling needs. A reporting module processing batch jobs at night has different resource requirements than an API serving 10,000 requests per second. In a monolith, everything scales together, and that gets expensive.
Third signal: the bounded contexts (in the DDD sense) are well understood. Services can then be cut along those boundaries. Without clear domain boundaries, splitting produces a distributed monolith, which is the worst-case scenario.
The Hidden Costs of Migration
In consulting engagements, we see teams underestimate the operational cost of microservices regularly.
Each service needs its own monitoring, logging, health checks, and alerting. A setup with Prometheus, Grafana, and Loki is not optional. Infrastructure complexity grows linearly with the number of services.
Then there is network complexity. Synchronous calls between services create latency chains. A request passing through five services becomes noticeably slower. Asynchronous communication via message queues solves the latency problem but introduces eventual consistency, and the team needs to handle that.
Testing gets harder too. Unit tests stay simple, but integration tests across service boundaries take effort. Contract testing with Pact helps but requires discipline:
provider:
name: OrderService
base_url: http://localhost:8080
pact_broker:
url: https://pact-broker.internal
token: ${PACT_TOKEN}
verify:
provider_states_setup_url: http://localhost:8080/pact-states
publish_verification_results: true
provider_app_version: ${CI_COMMIT_SHA}And then organizational overhead: microservices require clear ownership. Every service needs a responsible team. Without that assignment, a no-man’s-land emerges where bugs get bounced between teams.
The Modular Monolith as a Stepping Stone
Before starting a full migration, an intermediate step is worth considering: the modular monolith. Clear module boundaries are drawn within the existing codebase, with defined interfaces between modules, while keeping a single deployment.
// order-module/src/main/java/com/everbright/order/OrderFacade.java
public class OrderFacade {
// Public API of the module, only this class is visible externally
public OrderConfirmation placeOrder(CreateOrderRequest request) {
var order = orderService.create(request);
// Communication with other modules only through their facades
inventoryFacade.reserve(order.getItems());
return new OrderConfirmation(order.getId(), order.getTotal());
}
}This way, domain boundaries get validated in production before they become service boundaries. If two modules turn out to be tightly coupled, refactoring within a monolith is much cheaper than across services.
Most teams we advise benefit more from clean internal structure than from distributed systems. Modularize first, distribute later.
A Decision Framework for Practice
Five factors help guide the decision:
With fewer than 3 teams, a monolith or modular monolith usually works fine. At 4+ autonomous teams, coordination overhead in the monolith starts becoming the bottleneck, and microservices begin to make sense.
Deployment frequency matters too: if different parts of the application evolve at different speeds, that argues for services. If everything releases at the same cadence, splitting adds no value.
Operational maturity is a prerequisite. Microservices require the team to handle container orchestration, service mesh, distributed tracing, and automated deployment. Without those capabilities, migration becomes a risk. A solid cloud strategy is part of that.
If the team does not yet understand the business boundaries, stay in the monolith and modularize first. Poorly cut services cost more than an unstructured monolith, because every correction requires a distributed refactoring effort.
And budget: ongoing costs for infrastructure, monitoring, and operations increase with every service. For mid-sized companies, the math only works beyond a certain level of scale and complexity.
Conclusion
Microservices solve real problems, but only when those problems actually exist. The best architecture decision starts not with technology but with an honest look at team structure, domain complexity, and operational capabilities. Organizations running a monolith today should sharpen internal module boundaries before extracting the first service. Those adopting microservices need a clear plan for observability, ownership, and deployment automation. Otherwise they trade old problems for new ones. We help teams evaluate their architecture and find the right path forward →
Frequently Asked Questions
When should I migrate from monolith to microservices?
Three signals indicate readiness: teams have different deployment cadences and wait for each other, parts of the system need independent scaling, or domain boundaries are well understood. With fewer than three teams, a monolith works well. At four or more autonomous teams, coordination overhead becomes a bottleneck. Without clear domain boundaries, do not split because poorly cut services cost more than an unstructured monolith.
What is a modular monolith?
A modular monolith is a single deployment with clear internal boundaries and defined interfaces between modules. Communication stays within a single process. This approach validates domain boundaries in production before they become service boundaries. If two modules turn out tightly coupled, refactoring within a monolith is much cheaper than across distributed services.
What are the hidden costs of microservices?
Each service needs its own monitoring, logging, health checks, and alerting. Network complexity increases through latency chains and eventual consistency issues. Testing across service boundaries requires contract testing. Organizational overhead grows because each service needs an owning team. Infrastructure costs scale with the number of services. Teams often underestimate these operational costs when migrating.
How do you handle distributed tracing in microservices?
Distributed tracing follows requests across multiple services using unique request IDs passed through all calls. Tools like Jaeger or Zipkin collect traces and help identify latency bottlenecks. Each service logs with the trace ID, making it possible to reconstruct the entire request path. This is essential for debugging failures in microservice systems.
What is eventual consistency?
Eventual consistency means that after an update, not all services immediately see the new state. Asynchronous communication via message queues improves performance but introduces delays. All services eventually receive updates, but there is a window where they hold different views of data. Teams must design for this and handle edge cases like duplicate messages or partial failures gracefully.
Are microservices more expensive to operate than a monolith?
Operating costs are typically 30-50% higher than for a monolith because each service needs its own monitoring, logging, and alerting. Network complexity adds further overhead, and integration testing across service boundaries gets significantly more involved. These costs only pay off at sufficient scale or with deployment frequencies that justify the operational investment.
