Monolith vs Microservices

A monolith is a single deployable unit containing all application logic; microservices are independently deployable services each owning a specific business capability.

What It Really Means

This is not a debate with a universal winner. It is a spectrum of architectural choices with different trade-offs depending on your team size, domain maturity, operational capability, and growth trajectory.

A monolith packages everything — authentication, business logic, data access, background jobs — into one application. A function call between modules is a local, in-process operation. Transactions span the entire database. Deployment is one artifact. This is not a slur. A well-structured monolith with clean module boundaries (a "modular monolith") is a legitimate and often superior architecture for many organizations.

Microservices decompose the application into separate processes that communicate over the network. Each service owns its data, deploys independently, and can be written in different languages. A function call becomes an HTTP request or message queue publish. A database transaction becomes a distributed saga. This unlocks organizational scaling but introduces distributed systems complexity.

The key insight: microservices solve an organizational problem, not a technical one. If your monolith is slow because of bad database queries, microservices will not fix that. If your monolith is slow because 50 engineers are stepping on each other in the same codebase and deployment pipeline, microservices will fix that.

How It Works in Practice

Monolith Example: Shopify

Shopify processes over $200 billion in annual GMV through a modular Ruby on Rails monolith. They use a "componentized monolith" approach — the codebase is organized into components with enforced boundaries, but it deploys as one unit. They chose this because:

• One deployment pipeline to manage
• Local function calls are fast and reliable
• Database transactions keep data consistent
• Engineers can understand the full system

They invest heavily in modular architecture within the monolith, using tools like Packwerk to enforce component boundaries at the code level.

Microservices Example: Netflix

Netflix runs over 1,000 microservices. They moved to microservices because:

• Hundreds of engineering teams needed to deploy independently
• Different services have wildly different scaling needs (video encoding vs. recommendation vs. billing)
• A single deployment pipeline could not support their release velocity
• They have the operational maturity to manage distributed infrastructure

The Migration Path

Most successful microservices architectures started as monoliths. Amazon, Netflix, and Uber all began with monoliths and migrated when the organizational pain justified the distributed systems complexity. The typical path:

1. Start with a monolith — get to product-market fit fast
2. Modularize the monolith — enforce boundaries between domains
3. Extract services incrementally — use the strangler fig pattern
4. Stabilize — not everything needs to be a microservice

Implementation

Monolith: Clean Module Boundaries

Microservices: Distributed Coordination

Notice the difference in complexity. The monolith uses a single database transaction. The microservice version must handle partial failures with compensating transactions — the saga pattern.

Trade-offs

Choose Monolith When

• Your team has fewer than 15-20 engineers
• You are in the early stages and the domain is still evolving
• You do not have DevOps/platform engineering capacity for distributed infrastructure
• Strong consistency is critical across most operations

Choose Microservices When

• Multiple teams need independent deployment and release cadences
• Different components have very different scaling profiles
• You have the operational maturity (CI/CD, observability, container orchestration)
• Service boundaries are well understood from domain analysis

Common Misconceptions

• "Monoliths don't scale" — Monoliths scale horizontally behind load balancers. Stack Overflow serves millions of requests with a monolithic .NET application. The bottleneck is usually the database, not the application tier.

• "Microservices are the modern, correct architecture" — Microservices are a trade-off, not an upgrade. Many teams have migrated back from microservices to monoliths after finding the distributed complexity unjustified. The term "monolith" is not pejorative.

• "You need microservices from day one to avoid rewriting later" — Starting with a monolith is almost always the right move. You learn the domain, find the right boundaries, and can extract services later using the strangler fig pattern. Starting with microservices before understanding your domain leads to wrong service boundaries.

• "A modular monolith is just a monolith with folders" — A true modular monolith enforces boundaries at the code level (compile-time checks, package boundaries, interface contracts), not just directory structure. It gives you many benefits of microservices without the network overhead.

• "Microservices improve performance" — Microservices typically decrease performance for individual requests due to network overhead. They improve throughput by allowing independent scaling of bottleneck services.

How This Appears in Interviews

This is one of the most frequently discussed topics in system design interviews:

• "Would you use a monolith or microservices for this system?" — Discuss team size, domain maturity, consistency requirements, and scaling needs. Never answer dogmatically. See our system design interview guide.
• "How would you migrate from a monolith to microservices?" — Describe the strangler fig pattern, domain analysis, and incremental extraction.
• "What are the pitfalls of a microservices architecture?" — Discuss distributed transactions, data consistency, operational complexity, and network failure modes.
• Practice with our architecture interview questions.

Related Concepts

• Microservices Architecture — Deep dive into microservices
• Strangler Fig Pattern — Incremental migration strategy
• Domain-Driven Design — Finding the right service boundaries
• Event-Driven Architecture — Decoupling services
• Hexagonal Architecture — Clean internal architecture for either approach
• System Design Interview Guide — Comprehensive preparation
• Algoroq Pricing — Practice architecture interview questions