When to split your app into services — and when not to

"Should we use microservices?" is one of the most over-answered questions in software, and most of the answers are dogma in one direction or the other. Having built and run a platform of around seventeen separate services, my honest take is more boring — and more useful: it depends, and the deciding factors are knowable.

First, what a "service" actually is

Instead of one big program that does everything, you split the system into smaller programs that each own one job and talk to each other over the network. One handles login. One sends documents. One runs scheduled jobs. Each can be built, deployed, and scaled on its own.

That independence is the entire point — and also the entire cost.

What splitting genuinely buys you

• Independent deployment. A fix to the document service ships without touching login. Smaller, safer releases.
• Independent scaling. If document generation is heavy at month-end, you scale just that piece, not the whole system.
• Fault isolation. If one service struggles, the rest keep serving. A slow report doesn't take down the login page.
• Clear ownership. Each service has an obvious boundary and responsibility, which keeps a large codebase understandable.

On the platform I built, these were real wins — a print pipeline, batch jobs, translation, storage and auth could each evolve and scale on their own schedule.

What it costs — and this is the part people skip

Every network call between services can fail, lag, or arrive out of order. Data that used to live in one place is now spread out, so keeping it consistent takes real effort. You need deployment, monitoring, and logging that can see across all the pieces. And a bug can now hide between services, not just inside one.

That overhead is fixed. You pay it whether you have three services or thirty. On a small app, it can easily cost more than the monolith it replaced.

My rule of thumb

Start with one well-organised application. Split off a service only when a specific, concrete pressure demands it:

• A part of the system needs to scale differently from the rest.
• A part changes far more often and you want to release it independently.
• A part has genuinely different reliability needs (a background job shouldn't be able to affect checkout).
• Different teams need to own different parts without stepping on each other.

If none of those apply, a clean, modular single application is faster to build, cheaper to run, and easier to reason about. "Microservices" is not a maturity badge — it's a trade you make when the benefits finally outweigh a very real cost.

The skill isn't drawing seventeen boxes. It's knowing which lines are worth the price, and having the discipline to leave the rest alone.