The monolith vs microservices debate generates strong opinions, but the right answer depends on your context. This guide cuts through the hype to help you make a practical decision.
What Microservices Actually Are
Microservices architecture decomposes an application into small, independently deployable services. Each service:
- Owns its data and business logic
- Communicates over network protocols (HTTP, messaging)
- Can be deployed without affecting other services
- Can use different technology stacks
A monolith, by contrast, is a single deployable unit containing all functionality.
The distinction matters less than people think. Many successful systems are neither pure monolith nor pure microservices;they're somewhere in between.
Benefits of the Monolith
Monoliths get a bad reputation they don't deserve:
Simplicity: One codebase, one deployment, one database. New developers can understand the whole system.
Performance: In-process function calls are orders of magnitude faster than network calls. No serialization overhead.
Transactions: Database transactions work naturally. ACID guarantees across operations without distributed coordination.
Refactoring: Renaming a function or moving code is straightforward. Your IDE helps.
Debugging: Stack traces show the complete path. No need to correlate logs across services.
Development speed: Features often require changes in multiple areas. In a monolith, one PR can address everything.
Many successful companies run monoliths at scale: Shopify, Stack Overflow, Basecamp. The monolith isn't a mistake to be corrected;it's often the right choice.
When Microservices Make Sense
Microservices solve specific problems:
Team scaling: When you have multiple teams that need to work independently, service boundaries let teams move at their own pace without stepping on each other.
Different scaling needs: If one component needs 100x the resources of others, splitting it out lets you scale efficiently.
Technology diversity: Different problems benefit from different tools. A search service might use Elasticsearch while the main app uses PostgreSQL.
Fault isolation: A problem in one service doesn't necessarily bring down others. (Though shared dependencies often undermine this benefit.)
Independent deployment: Teams can deploy their services without coordinating with everyone else.
Note that most of these benefits relate to organizational scaling, not technical necessity. If you have a small team, microservices mostly add overhead without providing benefits.
The Distributed Systems Tax
Microservices aren't free. You pay a tax:
Network complexity: Services communicate over unreliable networks. Calls can fail, time out, or return slowly. You need retries, circuit breakers, and timeouts.
Data consistency: Transactions that span services are hard. Eventually consistent systems require different thinking than ACID databases.
Debugging difficulty: Finding the cause of a problem requires correlating logs and traces across services.
Operational overhead: Each service needs deployment pipelines, monitoring, logging, and potentially its own database.
Testing complexity: Integration tests require running multiple services. End-to-end testing becomes expensive.
Latency: Network calls add latency. A request that touches 10 services accumulates delay.
Versioning: Services have APIs. Changes must be backward compatible or coordinated carefully.
This tax is worth paying when you get real benefits in return. For small teams, you're often paying the tax without getting the benefits.
Team Size and Organization
Conway's Law states that systems reflect the communication structure of the organizations that build them. This cuts both ways.
If you have 5 developers working closely together, a monolith makes sense. They can communicate easily and don't need formal interfaces.
If you have 50 developers across 10 teams in different time zones, service boundaries help. They reduce the need for coordination and let teams work independently.
The common pattern: start with a monolith, split into services as the organization grows. Don't optimize for a team size you don't have.
Starting with a Monolith
For new projects, default to a monolith. This is not "technical debt";it's appropriate architecture for the stage you're at.
Build your monolith well:
- Keep modules loosely coupled
- Define clear interfaces between components
- Separate concerns (don't mix database queries with HTTP handling)
- Use dependency injection
- Write tests that don't couple to implementation
A well-structured monolith can be split into services later. A poorly-structured one will be hard to split;but a poorly-structured microservices system will be even worse.
Extracting Services Gradually
When you need to extract services, do it incrementally:
Identify boundaries: Look for components with clear interfaces and minimal coupling to the rest of the system. Background job processors, notification systems, and search indexes are common first extractions.
Strangle pattern: Keep the old code running while building the new service. Route traffic gradually to the new service. Remove old code when confident.
Start with the easiest: Don't extract the core domain first. Practice with less critical components.
Data ownership: The hardest part is usually splitting the database. Consider keeping shared data in the monolith until you're confident about ownership.
One at a time: Extract one service, stabilize, learn, then consider the next. Don't try to decompose everything at once.
Hybrid Approaches
Pure microservices (hundreds of tiny services) and pure monoliths aren't the only options:
Modular monolith: A single deployable unit with strong module boundaries. Code is organized as if it could be services, but isn't. Gives many microservices benefits without the operational overhead.
Macro-services: A few larger services rather than many small ones. Payment processing, search, and notification as separate services, with everything else in a monolith.
Backend for Frontend (BFF): A service that aggregates calls to multiple backends for a specific frontend. Useful when you have multiple client types with different needs.
The goal is solving your specific problems, not matching a theoretical ideal.
Decision Criteria
Consider microservices when:
- Multiple teams need to deploy independently
- Components have genuinely different scaling requirements
- Strong technical reasons require different technology choices
- You have the operational maturity to handle distributed systems
Stick with a monolith when:
- Your team is small (under 20 developers)
- You're still finding product-market fit
- Fast iteration matters more than scalability
- You don't have DevOps expertise for complex infrastructure
Red Flags
Signs you're doing microservices wrong:
- Every change requires coordinating multiple service deployments
- You're replicating data across services to avoid network calls
- Services share a database
- A PR touches multiple services
- You need a "platform team" just to keep things running
- Simple features take much longer than they should
Signs you need to split a monolith:
- Deployments are risky and require extensive coordination
- Teams are constantly blocking each other
- Build times are unreasonably long
- One team's bug crashes functionality for other teams
- You can't scale individual components independently
Conclusion
The monolith vs microservices debate is often framed as a binary choice between "legacy" and "modern." That framing is wrong.
Monoliths are appropriate for small teams, new products, and any situation where the simplicity benefits outweigh the scaling limitations. Microservices are appropriate when team and organizational scaling demand independent deployability.
Start simple. Add complexity only when you face problems that complexity solves. The best architecture is the simplest one that meets your actual needs;not the one that would be best if you were 10x your current size.