Comparison
Monolith or microservices: which architecture you need
Microservices solve an organisational problem, not a programming one. Without that problem, all you buy is the cost.
A monolith is one application holding everything: the interface, the business rules, the data access. It deploys in one place, is tested as one piece, and is debugged by following a single execution trace. Microservices divide the same functionality into small independent programs that talk to each other over the network: each can be written in a different technology, deployed separately, and multiplied on its own when it gets busy. It sounds obviously better until you count what comes with it — orchestration, an automated delivery pipeline per component, distributed request tracing, handling the cases where a component replies late or not at all, plus somebody permanently looking after all that infrastructure. The uncomfortable truth for technical marketing is that splitting primarily solves a coordination problem between teams. If you have one team of fewer than ten people, a monolith cleanly divided into modules gives you nearly every benefit invoked for the alternative, at a fraction of the monthly running cost.
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247
Key takeaways
Where the monolith wins
Simple deployment, fast debugging, a single test environment, small infrastructure bills. A small team changes a feature crossing three areas of the application in one modification rather than five coordinated with each other.
Where microservices win
Separate teams shipping without blocking each other, components that multiply independently when traffic arrives, and the isolation of a critical area, so that one failure does not take the whole application down with it.
The cost nobody puts in the quote
Every additional service means its own delivery pipeline, monitoring, logs, interface versioning and a plan for the moment it stops responding. Without somebody dedicated to running it, a distributed architecture degrades within a few months.
The middle road that works
A monolith organised into modules with clear boundaries, from which you later extract only the components that genuinely need independence — usually heavy processing or an integration with an unstable external system. That order is achievable; the reverse, much less so.
The thresholds where splitting starts to pay
The first threshold is organisational: you have two or more teams stepping on each other at every release and queueing behind one another to publish. The second is traffic: one part of the application consumes disproportionately more resources than the rest, and sizing the whole server for it has become visibly expensive. The third is risk: one component touches an unreliable external system and you want its failures contained. If none of these thresholds is met, splitting is an expense with nothing on the other side of the ledger.
When a supplier proposes microservices for a first version of a product, ask for two things in writing: the monthly infrastructure and operating cost of the proposed architecture, and the name of the person who will be accountable for it. If either answer is vague, the proposal serves their technical portfolio rather than your product. A first version needs users, not diagrams.
When you do not need us in order to decide
For an internal application used by thirty people, with predictable traffic and no peaks, the answer is a monolith and there is no point paying for an architecture review. Put that money into automated tests and a clean delivery process; they will buy you more stability than any diagram of separated components ever will.
Call us when the application has become hard to change, when a release takes a weekend and coordination, when one area of the product drags down the performance of the rest, or when the team has grown past the point where a single codebase turns into a tangle. Then we extract components one at a time, with measurements before and after, rather than rewriting everything from an idea about architecture.
Frequently asked questions
Do microservices make the application faster?
Generally they make it slower per individual request, because calls that were simple in-memory invocations become network calls. The gain lies in the ability to multiply busy components selectively, so we are talking about scalability rather than raw speed.
Can I start with a monolith and split later?
Yes, and it is the recommended route, on one condition: the modules must have boundaries respected from the beginning, with their own data and no direct calls into another module's internals. A disorderly monolith does not get split, it gets rewritten — and that is where the large budgets disappear.
How many people do I need to operate a distributed architecture?
Indicatively, at least one person dedicated to infrastructure and delivery, plus availability for out-of-hours intervention. Below that level, the development team spends a growing share of its time administering systems instead of writing features for customers.
What does a modular monolith mean in concrete terms?
One application in which each business area has its own space, its own tables and an internal interface through which the rest of the application calls it. Nothing reads another module's data directly. The result behaves like an orderly system while deploying and debugging like a single one.
Similar pages
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247