Microservices vs. Monolith: The Honest Tradeoff Analysis Nobody Gives You

Amazon Web Services runs on microservices. Shopify runs on a monolith. Basecamp runs on a monolith. Notion ran on a monolith until much later than most people assume. Stack Overflow served millions of developers from a monolith for over a decade. The microservices-versus-monolith question doesn't have a universal answer — it has a context-dependent answer, and the context that matters most has nothing to do with technology.

The Real Driver: Team Size and Ownership

Microservices solve an organizational problem, not a technical one. The core problem they solve is coordination overhead in large engineering organizations: when fifty teams are contributing to a single codebase, deploying that codebase requires coordinating fifty teams, and any team can accidentally break any other team's functionality. Microservices decompose the deployment and responsibility boundary in ways that allow teams to work independently.

If you don't have the organizational coordination problem — if your engineering team is under 30-40 people, all contributing to a manageable codebase — you don't have the problem that microservices solve. You have the costs of microservices without the benefits: distributed systems complexity, network latency between services, operational overhead of running multiple deployments, and the difficulty of making atomic changes across service boundaries.

The Costs Nobody Talks About

Microservices proponents discuss their benefits extensively. The costs receive less attention but matter more for teams making the decision at early scale.

Distributed transactions are hard. Operations that touch multiple services atomically require either careful design to make them unnecessary, two-phase commit protocols (which are complex and slow), or eventual consistency (which is correct but mentally challenging to reason about). In a monolith, a database transaction handles atomicity. In a microservices architecture, you're designing your own distributed transaction protocol, and getting it wrong produces data inconsistencies that are difficult to detect and painful to correct.

Local development is harder. Running a monolith locally requires one process. Running twenty microservices locally requires twenty processes, their dependencies, inter-service networking, and the orchestration to start them in the right order. Docker Compose helps. It doesn't fully solve the problem. Engineers who can develop and test efficiently in a monolith often can't iterate as fast in a microservices environment.

Code review across service boundaries is awkward. When a feature spans three services, the review involves three PRs, each owned by potentially different teams, with dependencies that may not be obvious from any individual PR. Reviewers who could evaluate the complete feature in a monolith are evaluating fragments in a microservices architecture.

The Right Decomposition Point

If you're building a monolith today, the right time to extract a service is when a specific component meets two criteria simultaneously: it has a clear ownership boundary (a single team owns it and no other team needs to modify it directly), and it has distinct scaling or deployment requirements (it needs to deploy at a different frequency or scale independently of the rest of the system).

Until both criteria are met, the component should stay in the monolith. A well-structured monolith with clear internal module boundaries can accommodate significant team and scale growth before the organizational coordination problem becomes the binding constraint. Don't pay the microservices operational tax before you need the microservices organizational benefit.