Monolith or Microservices: What an SME Actually Needs

Every few years an architecture becomes fashionable and gets recommended to companies it was never designed for. Microservices are the clearest recent example. They solve real problems — for organisations that have those problems.

If you are a company of under fifty people, you almost certainly do not, and this article is about why, and where the genuine exceptions are.

What the words mean

A monolith is one application. One codebase, one deployment, usually one database. When you change something, you deploy the whole thing. This is how most software has always been built, and the word acquired a sneer it does not deserve.

Microservices split the application into small independent services, each with its own codebase, deployment and often its own database. They talk to each other over the network.

What microservices actually buy you

Three things, and it is worth being precise because the benefits are usually stated too vaguely.

Independent deployment by independent teams. If forty engineers in six teams all deploy to one application, they queue behind each other and a bad change blocks everyone. Splitting the system lets each team ship without coordinating. This is the real reason large organisations adopt microservices, and it is an organisational benefit before it is a technical one.

Independent scaling. If one part of your system uses vastly more resources than the rest — video encoding, say, or a search index — you can scale that part alone instead of running twenty copies of everything.

Technology isolation. One service can be written in a different language, or use a different database, without dragging the rest along.

What they cost

The costs are less often stated, and they are substantial.

A function call becomes a network call. In a monolith, one part of the code calling another is instantaneous and cannot fail halfway. Across the network it can be slow, it can time out, it can succeed but the response gets lost. Every one of those cases is now yours to handle, everywhere.

Debugging gets much harder. A bug that spans four services means four sets of logs, and you need distributed tracing to follow one request through the system. That is infrastructure you now run.

Data consistency becomes a design problem. One database and one transaction gave you consistency for free. Split across services, you are writing compensating logic and living with things being briefly wrong.

Operations multiply. Fifteen services need fifteen deployment pipelines, fifteen sets of monitoring and alerts, fifteen dependency upgrade paths. That is a job, and if nobody has it, it does not get done.

The rule of thumb that has held up: microservices trade development complexity for operational complexity. That is a good trade when you have a platform team and a bad one when you have three developers.

What an SME should build

For almost every small and medium business, the answer is a well-structured monolith. One application, deployed as one thing, but organised internally with clear boundaries between areas of the business.

That last part is what makes it work. The failure people remember as "the monolith" is usually not the deployment model — it is an application with no internal structure, where everything reaches into everything else. That is a discipline problem, and splitting it across a network does not fix it; it just makes the tangle harder to see.

Build the boundaries inside the application first. If you ever genuinely need to split it, clean internal boundaries are exactly what makes that possible.

The genuine exceptions

There are cases where separating something out is right even for a small company. Look for a part of the system that is genuinely different:

• A workload with completely different resource needs — heavy image or video processing, a machine learning model, a long-running job. Running that separately keeps it from starving your website.
• A part that has to scale independently and unpredictably — a public API with spiky traffic, for instance.
• Something with different availability requirements — if payment processing must stay up while the rest can tolerate a deploy.
• A genuinely separate product that happens to share a login.

Note the shape of these: they are one or two services split off a monolith for a specific reason. That is a completely different thing from starting with fifteen services because it is the modern way.

Practical advice

Start with a monolith. Always. You do not know where the boundaries are yet. Splitting early means guessing, and a wrong boundary is far more expensive to fix than a missing one.

Invest in internal structure from the beginning. Clear modules, explicit interfaces between areas, no reaching into another module's data directly. This costs almost nothing at the start and is nearly impossible to retrofit.

Split when something specific forces it, not on a schedule. The signal is concrete: this part needs different scaling, or a specific team is genuinely blocked, or one workload is destabilising everything else.

Be honest about your operational capacity. If nobody at your company is on call, you cannot run a distributed system responsibly. That is not a criticism; it is a constraint, and designing within it is competence rather than compromise.

The summary

Microservices are a solution to organisational scaling problems that appear at a size most companies never reach. If you have fewer than fifty people, a well-structured monolith will serve you better on almost every axis: cheaper to build, easier to debug, faster to change, and far less to operate.

Build the boundaries. Skip the network between them until something specific makes you add it.