Microservices vs Monolith: What to Choose?
Every CTO eventually hears: "We need microservices, like Netflix!". But Netflix has 10,000 engineers and billions of dollars. And you have 5 developers and an MVP. Let's figure out when a monolith is wisdom, and when microservices are a necessity.
Visual Comparison
🏛️ Monolith
All modules in one process
🧩 Microservices
Each service is independent
When Monolith is the Right Choice
- Early-stage startup: You need development speed, not scale. A monolith allows you to quickly change code without orchestrating 20 services.
- Team < 10 people: You simply don't have resources to maintain microservices infrastructure (Kubernetes, Service Mesh, Distributed Tracing).
- Low load: If you have 1000 RPS, a monolith will handle it on one server. Why complicate?
When It's Time to Move to Microservices
- Different teams, different paces: The payments team wants to deploy 5 times a day, and the reports team — once a week. A monolith forces everyone to wait for each other.
- Different load on modules: The mobile app API gets 100k RPS, and the admin panel — 10 RPS. In a monolith, you scale everything together (expensive). In microservices — only what's needed.
- Technological freedom: Want to write an ML module in Python, and the main backend in Go? In a monolith, it's pain. In microservices — it's normal.
Golden Middle: Modular Monolith
Start with a monolith, but write it as future microservices. Divide code into modules with clear boundaries (Domain-Driven Design). When the time comes, you'll just extract the module into a separate process.
NineLab Advice: Microservices are not architecture. They're organizational structure. If you don't have multiple teams, you don't need microservices.
Related services
FAQ for this topic
Traffic shape and data rarely match prod. You need scenarios, the same metrics as prod, and gradual ramp with rollback.
Often DB/query plans, connection pools, synchronous external calls, and queues are the first suspects for a quick checklist.
Not necessarily: invalidation, cold starts, and key skew can hurt. Cache is designed around read models and SLOs.
When vertical scaling and query tuning hit a ceiling and data growth is predictable along a shard key.
Want to apply this in practice?
Tell us about your system — we’ll propose a work plan and the metrics worth fixing in an SLA/SLO.
Related articles
Excel Isn't Enough Anymore: 5 Signs Your Business Needs a Custom App
Clear signs your company has outgrown spreadsheets: accounting mistakes, chat-based approvals, lost requests, and no end-to-end visibility. Learn when it’s time to automate business processes and build an internal web app (portal, customer cabinet, ticketing workflow) that fits how your team actually works.
Read ArticleHow to DIY stress test your website and know when it will crash
Instructions on testing your site yourself: basic tools (k6, Apache Benchmark), common pitfalls, and a detailed breakdown of why online stores fall during ad campaigns.
Read ArticleSaaS Platform Development: Why Writing Code Is Only Half the Battle
The full cycle of SaaS product creation: from architecture design to server configuration for thousands of users. Why 90% of startups fail not because of code, but because of infrastructure.
Read ArticleHigh-Load System Architecture: Handling a Million Requests per Second
Breaking down the principles of building systems that don't fail under load: horizontal scaling, load balancers, caches, and queues.
Read Article