Monolith vs. Microservices
The Architecture Decision That Costs Millions to Reverse
Every startup should start with a monolith. Most know when to split. Few know the true cost of premature decomposition.
📊 Scoring Matrix
Up to 20 engineers
20+ with domain ownership
Single deploy (simple)
Independent deploys (complex)
In-process calls (fast)
Network calls (overhead)
Single codebase (easy)
Distributed tracing (hard)
Lower infrastructure
2-5x infrastructure cost
Vertical (limited)
Horizontal (unlimited)
📋 Executive Summary
Start monolith, extract when Conway's Law demands it. The worst outcome is premature microservices.
Premature microservices add 500K-1M in infrastructure and coordination costs per year.
🎯 Decision Framework
- ✓ Team < 20 engineers
- ✓ Rapid prototyping/MVP phase
- ✓ Simple domain model
- ✓ Cost-sensitive infrastructure
- ✓ Team > 50 with clear domain ownership
- ✓ Independent scaling requirements
- ✓ Polyglot technology needs
- ✓ Multiple autonomous teams
Under 20 engineers? Monolith. 20-50 with clear domains? Start extracting. Over 50? You probably already need microservices.
🌐 Market Context
The "monolith-first" approach (Fowler, 2015) has become consensus. Amazon, Shopify, and others have publicly shared monolith-to-microservices journeys.
2024-2025 trend: "modular monolith" — monolith boundaries with microservice-ready architecture. Best of both worlds.
🛠️ Related Tools
Keep exploring
Need Help Deciding?
Book a 60-minute advisory session. I'll map these frameworks to your specific context, team size, and budget.