Monolith vs Microservices
Start with a monolith, extract microservices when complexity demands it
Overview
The monolith versus microservices decision is perhaps the most impactful architectural choice a team makes, because it determines how you build, deploy, scale, and organize your engineering teams. A monolithic architecture deploys the entire application as a single unit: one codebase, one build artifact, one deployment pipeline. This approach dominated software engineering for decades and remains the right choice for most early-stage products. Microservices architecture decomposes the application into independently deployable services, each owning a bounded context of business logic and its own data store. This approach gained prominence through Netflix, Amazon, and other hyperscalers who needed to scale engineering teams and systems independently. However, the industry has seen a correction: many teams that prematurely adopted microservices have migrated back to monoliths or adopted modular monolith patterns (Amazon Prime Video's 2023 migration being a notable example). The key insight is that microservices are an organizational scaling solution as much as a technical one. They make sense when you have multiple autonomous teams that need to deploy independently, but they introduce distributed systems complexity that a single team should rarely take on. The best approach for most projects is to start with a well-structured monolith with clear module boundaries, and extract services only when specific scaling, deployment, or organizational pressures demand it.
Head-to-Head Comparison
When to Choose Each
Choose Monolith when...
- Your team is small (fewer than 10-15 engineers) and can work effectively in a shared codebase without severe merge conflicts or coordination overhead.
- You are building an early-stage product where speed of iteration matters more than independent scalability, and your traffic patterns are not yet well understood.
- Your domain requires strong data consistency with ACID transactions spanning multiple entities, which is far simpler with a single database.
- You want to minimize operational complexity and infrastructure costs: one deployment pipeline, one monitoring stack, one on-call rotation.
- Your modules have high coupling and shared data models that would require extensive inter-service communication if split into separate services.
Choose Microservices when...
- Your organization has multiple autonomous teams (10+ engineers total) that need to deploy independently without coordinating release schedules.
- Different parts of your system have fundamentally different scaling requirements (e.g., a read-heavy feed service vs. a CPU-intensive encoding service).
- You need technology heterogeneity: some services benefit from different languages, frameworks, or databases based on their specific workload characteristics.
- Fault isolation is critical: a failure in one domain (e.g., recommendation engine) should not bring down core functionality (e.g., checkout).
- Your monolith has grown to the point where build times exceed 15 minutes, deployments take hours, and a bug in one module regularly causes outages in unrelated features.
Architectural Impact
Frequently Asked Questions
Should I start with microservices?
Almost always no. Starting with microservices means paying the distributed systems complexity tax before you understand your domain boundaries, traffic patterns, and scaling needs. Start with a well-structured monolith with clear module boundaries. Extract services only when you have concrete evidence that a specific module needs independent scaling, deployment, or team ownership.
How do I know when to break up a monolith?
Look for these signals: deployment frequency is limited because teams are stepping on each other, build and test times exceed 15 minutes, specific modules have fundamentally different scaling needs, a bug in one module causes outages in unrelated modules, or your organization has grown to 3+ teams that need deployment independence. If none of these apply, the monolith is likely still the right choice.
What is a modular monolith?
A modular monolith is a single deployable application organized into well-defined modules with explicit boundaries, similar to bounded contexts in Domain-Driven Design. Modules communicate through defined interfaces rather than direct database access. This provides the organizational clarity of microservices while avoiding distributed systems complexity, and makes future service extraction straightforward.
How do microservices handle transactions across services?
Microservices cannot use traditional ACID transactions across service boundaries because each service owns its own database. Instead, they use patterns like the Saga pattern (a sequence of local transactions coordinated through events or orchestration), eventual consistency, and compensating transactions to undo partial operations. This is significantly more complex than a single database transaction.
Do microservices always improve performance?
No. Microservices often increase latency because requests must traverse network calls between services, each adding serialization, network round-trip, and deserialization overhead. A monolith can handle a request with in-process function calls that take microseconds, while the same logical request across microservices might take tens of milliseconds. Microservices improve scalability (the ability to handle more load) but do not inherently improve per-request performance.
Try This Comparison in Vetora
In Vetora, model a monolithic architecture as a single Service node handling all business logic, connected to one Database node. Then model a microservices architecture with multiple Service nodes, each with its own Database, connected through an API Gateway and Event Stream. Run identical traffic scenarios against both designs and compare end-to-end latency, failure blast radius, and resource utilization. The AI grading report will highlight trade-offs in reliability and operational complexity.
Start Simulating Free