Microservices decompose an application into independently deployable services. Done correctly at the right scale, they allow large teams to ship independently and systems to scale components selectively. Done prematurely, they take all the complexity of a distributed system and add it to a team that does not yet understand their own domain boundaries, producing a distributed monolith that is harder to operate than what it replaced.
Analysis Briefing
- Topic: Monolith vs microservices architecture and the cost of premature decomposition
- Analyst: Mike D (@MrComputerScience)
- Context: Claude Sonnet 4.6 asked the right question. This is the full answer.
- Source: Pithy Cyborg | AI News Made Simple
- Key Question: What specifically goes wrong when a team of 8 engineers migrates to microservices?
What a Monolith Gets Right That Microservices Make Hard
A well-structured monolith is not a ball of mud. It is a single deployable unit with internal module boundaries, clear separation of concerns, and a single database. Changing it requires changing one codebase and deploying one binary. Debugging it requires one log stream and one stack trace. Testing it end-to-end requires standing up one service.
Cross-cutting concerns that are trivial in a monolith become distributed systems problems in microservices. A database transaction that spans two tables is a single atomic operation in a monolith. The same operation spanning two microservices with separate databases requires a distributed transaction or a saga pattern, both of which are significantly more complex and have more failure modes.
Observability that is straightforward in a monolith (one log file, one metrics endpoint, one distributed trace) requires a full observability platform in microservices: centralized logging (ELK, Grafana Loki), distributed tracing (Jaeger, Zipkin, Honeycomb), and a service mesh or sidecar proxies to collect metrics from every service. A team of 8 that does not yet have this infrastructure will spend more time debugging production issues than shipping features.
The Distributed Monolith Anti-Pattern
The most common microservices failure mode is the distributed monolith: services that were decomposed too early along the wrong boundaries and still cannot be deployed independently. Services that must be deployed in a specific order. Services that share a database, negating the isolation benefits. Services with synchronous chains where Service A calls B which calls C which calls D, and any slow or failing service collapses the entire chain.
The root cause is premature decomposition. Before a team has operated a system in production and discovered through real usage which parts change together and which change independently, the domain boundaries are guesses. Those guesses are frequently wrong. Wrong service boundaries in a monolith require internal refactoring. Wrong service boundaries in microservices require cross-team contract negotiations, coordinated deployments, and API versioning.
The diagnostic question is: “can this service be deployed independently without coordinating with any other team?” If the answer is no for most of your services, you have a distributed monolith.
When Microservices Are Actually the Right Answer
Microservices solve specific problems that arise at specific scales. The problems they solve are team coordination at large headcount, independent scaling of components with different resource profiles, and independent deployment of components with different release cadences.
A team of 8 engineers does not have team coordination problems. A service that is not yet at the traffic level where selective scaling matters does not benefit from independent scaling. An organization without multiple teams shipping independently does not benefit from independent deployments.
The companies that regret early microservices migration are those that treated microservices as an architectural best practice to adopt rather than a solution to a specific problem they were experiencing. Stack Overflow runs one of the highest-traffic websites in the world on a small number of servers with a mostly monolithic architecture. Prime Video moved from microservices back to a monolith and published the case study: costs dropped by 90% and operational complexity dropped substantially.
The right time to decompose is when you feel the pain that microservices solve: teams blocking each other’s deploys, a specific component needing to scale independently, or clear domain ownership requiring autonomous operation. Not before.
What This Means For You
- Start with a modular monolith and extract services only when you have evidence of the specific problem that decomposition solves, because the cost of premature decomposition is paid in operational complexity on every incident, deploy, and debugging session.
- Never let two services share a database, because a shared database is the single dependency that eliminates independent deployability and creates the tight coupling that makes microservices coordination more expensive than a monolith.
- Build full observability before extracting your first service, because debugging a distributed system without centralized logs, distributed tracing, and service-level metrics is significantly more expensive than debugging a monolith, and that cost appears on every production incident.
- Use the two-pizza team rule as a decomposition signal, because microservice boundaries that align with team boundaries allow genuinely independent ownership, while boundaries that cut across team lines create a distributed monolith regardless of whether the code is physically separated.
Enjoyed this deep dive? Join my inner circle:
- Pithy Cyborg | AI News Made Simple → AI news made simple without hype.