Monolith vs microservices: why your project probably doesn't need the latter

You've probably heard the story. A startup begins with a monolith, grows, flounders, migrates to microservices, and everything works out. Netflix did it. Amazon did it. Spotify did it.

What's often overlooked is the context. Netflix migrated when it had 100 million users and thousands of engineers. Your project probably has neither. And that completely changes the equation.

In the monolith vs. microservices debate, the most common mistake isn't choosing the wrong architecture. It's choosing it too early, based on what companies completely different from yours are doing.

What each thing is (without beating around the bush)

A monolith is an application where all the code lives together: business logic, user management, payments, notifications. It's deployed as a single unit. When you update one part, you deploy the whole thing.

Microservices divide an application into independent services. Each service performs a single task, has its own database, and communicates with the others via APIs or messaging. They are deployed separately.

So far, so good in theory. Practice is where things get complicated.

What the monolith does well (and nobody wants to admit)

The monolith has a bad reputation. It sounds old-fashioned, limited, and "not to scale." But there are solid reasons why it remains the best option for most projects.

Operational simplicity. One codebase, one deployment, one database. You don't need container orchestrators, service mesh, API gateways, or distributed traceability tools. Your team can focus on building product instead of maintaining infrastructure.

Development speed. In a monolithic environment, refactoring is simply changing code within the same repository. There's no need to coordinate changes across five services, version APIs, or manage communication contracts. For small teams (fewer than 10-15 developers), this simplicity translates directly into speed.

Direct debugging. When something fails in a monolith, the stack trace tells you exactly where. In microservices, a single error can involve tracing calls between six services, with distributed logs and network latencies complicating diagnosis.

Simple transactions. If your operation needs to update three tables atomically, in a monolith it's a database transaction. In microservices, it's a saga pattern with trade-offs, idempotence, and partial fault management. The complexity multiplies.

Cost. A monolith runs on a single server or a simple cluster. Microservices require infrastructure for each service, load balancers, message queues, and service registries. According to InfoQ data, the operating cost of a microservices architecture can be 3 to 10 times higher than that of an equivalent monolith in the initial stages.

What microservices do well (when you need them)

Microservices are not a passing fad. They solve real problems. But problems that arise at a specific scale and level of complexity.

Independent scaling. If 90% of your traffic goes to a specific module (search, for example), with microservices you can scale only that service instead of replicating the entire application. In a monolith, it's all or nothing.

Autonomous teams. When you have 50, 100, or 200 developers, a monolithic approach becomes an organizational bottleneck. Everyone works on the same code, merge conflicts are constant, and deployments are painstakingly coordinated. Microservices allow each team to own their service and deploy at their own pace.

Heterogeneous technology. Each service can use the language and database that best suits its needs. The search service might use Elasticsearch, the payments service might run in Java with strict type guarantees, and the notifications service might be a serverless function. In a monolith, everything shares the same stack.

Fault isolation. If one microservice fails, the others can continue functioning (if they are well-designed). In a monolith, a failure in one module can bring down the entire application. This is critical in systems where availability is a business requirement.

The questions you should ask yourself

Before choosing between monolith and microservices, answer this honestly:

How many people are on your development team? If it's fewer than 10-15, a monolithic approach will give you more speed. The organizational overhead of microservices isn't justified with small teams. This isn't just an opinion; it's a recurring pattern in the industry.

Is your product already gaining traction? If you're validating an idea, building an MVP, or in the early stages of growth, a monolithic approach allows you to iterate faster. You can migrate later, once you have real data on where the bottlenecks are. Investing in microservices before you have users is optimizing for problems that may never arise.

Are you having real scaling problems? "We need to scale" and "we're going to need to scale someday" are very different things. If your monolith handles current traffic without breaking a sweat, you don't need microservices.

A well-built monolith using Django or similar frameworks can handle millions of requests per day. This isn't a limitation; it's a solution that works.

Does your team have experience with distributed systems? Microservices don't eliminate complexity; they shift it from the application to the infrastructure. You need people who understand networking, observability, container orchestration, resilience patterns, and distributed debugging. If your team lacks this experience, the learning curve will slow development for months.

Can you afford the operating costs? More services mean more infrastructure, more monitoring, more alerts, and more points of failure. According to Martin Fowler , microservices have a complexity "premium" that is only justified when the alternative (the monolith) can no longer absorb the growth.

The middle ground that no one mentions

The monolith vs. microservices debate is often presented as a binary choice: monolith or microservices. Black or white. But there's a middle ground that works very well for most growing projects: the modular monolith.

A modular monolith is an application that is deployed as a single unit, but whose code is organized into independent modules with clear boundaries. Each module has its own logic, its own data models, and a well-defined interface with the others.

The advantage: you get the operational simplicity of a monolith with the logical separation that later makes it easy to extract services if you really need them. It's not a compromise: it's a strategy.

Shopify is a well-known example. According to their own engineering team, they opted to modularize their monolithic platform instead of migrating to microservices. They process billions in transactions with this architecture. If it works for them, it will probably work for your project.

When does migration make sense?

If you already have a monolith and are considering microservices, there are clear signs that the time has come:

Deployments are a bottleneck. Several teams need to deploy at different rates, and the monolithic infrastructure is preventing this. Merge queues are growing, and deployments are being delayed by days.

One module needs to scale significantly better than the rest. If 5% of your code consumes 80% of the resources, it makes sense to extract it as a separate service. But only that module, not the entire system.

The monolith has become unmanageable in terms of technical debt. The codebase is so large and tightly coupled that no change is safe. Before migrating to microservices, consider whether refactoring the monolith wouldn't solve the problem with less risk.

Your organization has grown to the point where it needs autonomous teams. If you have 40+ developers and coordination within the monolith is no longer working, dividing into services may be the organizational (not just technical) answer.

If none of these signals fit, you probably don't need microservices. And that's okay.

Architecture is not a statement of intent

Choosing a monolithic architecture doesn't mean your project is small. Choosing microservices doesn't prove your team is modern. Architecture is a tool, not an identity.

What matters is that the decision is based on data, not trends. It should address real problems with your team and your product, not what Netflix did ten years ago.

Start simple. Build a well-structured, modular monolith with clear boundaries between modules. When the data tells you that you need to distribute, you'll have a solid foundation from which to do so.

And if that moment never comes, you'll have saved yourself months of unnecessary complexity.