Monolith vs Microservices: What an Indian Startup Should Actually Build

Every six months a founder asks us if their new product should launch on microservices because they have read three articles about how Netflix runs. The honest answer is almost always no, and the reason has more to do with team size than with the technology.

What microservices actually buy you

Microservices solve four problems and only four:

• Independent deployment. Different teams ship at different cadences without stepping on each other.
• Independent scaling. One service can grow horizontally without lifting the whole fleet.
• Independent technology choice. Different problems use different stacks (e.g. Python for ML, Go for low-latency).
• Failure isolation. A bad release in one service doesn't take down the rest.

If you don't have multiple teams shipping multiple times a day, you don't have those problems yet. Splitting services to anticipate them adds a real cost — distributed tracing, network failures between every two functions, integration tests that span four repos — without delivering the upside.

What you almost certainly want first

A modular monolith: one codebase, one deployment unit, but with strict module boundaries inside. In Node.js this looks like a NestJS or Fastify app with one folder per business domain (orders, users, payments) and explicit imports between them. In Python it is a Django project with separate apps. In Go it is a single binary with internal packages.

The boundaries do real work even when the code is in one repo:

• Each module owns its data — no other module reads its tables directly.
• Modules talk through service interfaces, not by reaching into each other's internals.
• Database migrations within a module don't break others.

This setup gives you 80% of the discipline benefits of microservices and almost none of the operational pain.

When to actually split

Three signals indicate it is time to break out a microservice:

1. Team size. When more than 6–8 engineers are touching the same monolith and merge conflicts are a daily event, owning a separate deployment unit per team starts paying back.
2. Scaling shape. When one part of your traffic (say, image uploads or search) needs 10x more capacity than the rest, splitting it lets you scale that piece without paying for the others.
3. Different runtime needs. When one workload genuinely benefits from a different stack — for instance, an ML model that needs Python and GPUs while your app is on Node — splitting becomes obvious.

If none of these are true today, splitting is a premature optimisation. Worse, it is one that will slow down your first 18 months of feature delivery in exchange for benefits you can't yet use.

The migration path that actually works

When the time does come, the cleanest pattern is the strangler fig:

1. Pick the module with the strongest case (independent scaling, different team, different runtime).
2. Build the new service alongside the monolith.
3. Route a small percentage of traffic to the new service via a feature flag.
4. Watch metrics for a few weeks. Roll back if anything is off.
5. Cut over fully, then delete the old code from the monolith.

The mistake people make is starting at step 5 — extracting the new service in one big merge that ships on the same day. Don't do that.

Summary

Start with a well-structured monolith. Split when team size, scaling shape, or runtime needs force the issue. Don't pre-pay for an architecture that solves problems you don't have. Most successful Indian startups we have worked with were happily on a single Django or NestJS service for the first ₹10 crore of ARR — and that's not a story you read in conference talks, but it is the one that ships.