Monolith vs Microservices
A monolith deploys all functionality as a single unit, while microservices decompose the system into independently deployable services — but the right choice depends on team size, domain complexity, and deployment frequency, not architectural fashion.
A monolith is a single deployable unit containing all business logic. It's simpler to develop, test, debug, and deploy — one codebase, one build, one process. Database transactions are straightforward. Stack Overflow serves 1.3 billion monthly page views from a monolith running on a handful of servers.
A microservices architecture decomposes the system along business domain boundaries. Each service is independently deployable, scalable, and owned by a small team. Netflix runs 1,000+ microservices because their 2,000+ engineers need to deploy independently without coordination.
The key insight: microservices are an organizational scaling pattern, not a technical one. If you have 5 engineers, a monolith is almost always correct. If you have 500 engineers, microservices let teams deploy without stepping on each other.
Tradeoffs
Monolith — Strengths
- Simple to develop, test, deploy, and debug
- In-process calls are nanoseconds, not milliseconds
- Database transactions are trivial (ACID across the whole system)
- One codebase to search, one build to run, one process to monitor
- Stack Overflow proves a monolith can serve billions of page views
Monolith — Weaknesses
- Deployment couples unrelated changes (a CSS fix deploys with a database migration)
- Scaling is all-or-nothing (can't scale just the CPU-intensive component)
- Technology lock-in (one language, one framework for the whole system)
- Large codebases become hard to navigate and modify safely
- Deploy queue: with 100+ engineers, merging and deploying becomes a bottleneck
Microservices — Strengths
- Independent deployment: teams ship without coordinating
- Independent scaling: scale the hot service, not the whole system
- Technology diversity: Python for ML, Go for networking, Java for business logic
- Fault isolation: one service crashing doesn't take down everything
- Clear ownership: small teams own small services end-to-end
Microservices — Weaknesses
- 30-50% infrastructure overhead (service mesh, tracing, discovery)
- Network latency replaces function calls
- Distributed transactions require sagas (complex, eventually consistent)
- Operational complexity: monitoring, debugging, and on-call across dozens of services
- Requires platform team investment (Kubernetes, CI/CD pipelines per service)
Likely Follow-Up Questions
- What is a distributed monolith and how do you avoid it?
- How would you migrate a monolith to microservices incrementally?
- What's the minimum team size where microservices make sense?
- How does Conway's Law influence the monolith vs microservices decision?
- What is the modular monolith pattern and when is it the right choice?
- How do you handle database transactions that span multiple microservices?
Related Concepts
Source: editorial — Synthesized from Stack Overflow architecture, Shopify's modular monolith talks, Netflix/Uber architecture blogs, Segment's reverse migration post, and Amazon's API mandate history