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

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

1. 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.
2. 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.
3. 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.