Monolith or microservices: why not start with microservices

Should you build your app as several small independent services, or as a single block? For a product that is starting out or still small, the single block, called a monolith, is most often the right start. Microservices answer problems you probably do not have yet.

Two ways to organise an app

A monolith is an app whose code all lives together: accounts, payments, notifications, dashboard. It is deployed in one go, as a single program.

Microservices split the app into several small programs, each in charge of one task, talking to each other over the network (often through APIs). One service for accounts, one for payments, one for notifications.

The analogy: a restaurant and a food court

A monolith is a restaurant with a single kitchen: everyone crosses paths, passes plates along, and a cook in trouble just calls out to the neighbour.

Microservices are a food court of independent stalls: each has its own cook, its own equipment, its own till. The advantage is that one stall can close without stopping the others, and each can grow at its own pace. The drawback is that you must organise deliveries between stalls, shared billing, opening hours, and fix the miscommunications.

When you serve ten covers, the food court does not help: it adds work.

What microservices cost

Splitting is not free. You trade code problems for coordination problems:

• The network becomes a source of failures. A call between two services can be slow or fail, which does not happen when two parts of the code talk inside one program.
• Data gets scattered. An operation touching two services can no longer be validated in one go: you must handle the case where one half succeeds and the other does not.
• Deployment multiplies. Each service has its own environment, monitoring and updates.
• Understanding a bug takes longer. You have to follow a request through several services.
• It takes people to run them. Microservices are often justified by large teams that must not step on each other.

What a well-kept monolith allows

A monolith is not a tangle. Well organised, it has clearly separated modules (accounts, billing, notifications) that do not bleed into each other.

• You move fast: a change touches one place, one deployment.
• Testing is easy: everything is in the same place.
• You can get the split wrong and fix it painlessly, which is valuable when the product changes every week.
• If one day a part must live on its own, a well-separated module is far easier to extract than a knot of tangled code.

When microservices make sense

There are real reasons to split, for example:

• several teams working in parallel who keep blocking each other;
• one specific part that must scale far more than the rest;
• technical or security constraints that require isolating a piece.

If you cannot name one of these reasons, the complexity has no payoff yet. It is better to move ahead as a monolith, keep the code in clean modules, and split later if a real need appears.

Warning signs

If you inherit an app that is already split, a few useful questions:

1. Does each service have a real reason to exist on its own?
2. Do the services share the same database, cancelling part of the point?
3. Do you need to change three services to alter a single rule?

Three "yes" or "we do not know" answers often point to complexity that gives nothing back, and that can be simplified. For other signs of code that holds you back, see technical debt.

Key takeaway

Start with a monolith organised in modules, and only split when a specific need requires it. The simplicity of the start is not a flaw of youth: it is what lets you change direction fast.

And for your product?

If your app is already split into several services and every change has become painful, or if you inherit code and are not sure whether to merge it or keep it as is, that is a typical case for a project takeover. We can talk it through in 30 minutes, based on what you have in front of you.