Microser­vices or Monolith: A Decision Guide for Teams and Products

Start with a modular monolith and only extract individual parts as microservices once there is a concrete reason: several teams blocking each other during releases, an area with a significantly different scaling or availability need, or a technically different component. Microservices are not a mark of quality but a tool with noticeable operating costs.

Large platforms show what distributed services can do. But what works for corporations with hundreds of developers is often needlessly complex and expensive to run for a mid-sized product. This article offers a reliable decision guide: a comparison, criteria, common misconceptions and a way to get from a monolith to services step by step.

Two archi­tec­tures at a glance

A monolith is an application that is built and delivered as a whole. All functions – such as user management, orders and billing – run in one process and usually share a database. With microservices, the application is split into independent services. Each service is responsible for one business area, often has its own data storage and is released independently. Communication runs via interfaces or messages.

In between lies the modular monolith: an application that is run as one unit but is internally divided into clearly delimited modules. The overview below compares it with microservices.

Criterion	Modular monolith	Microservices
Deployment	one unit, one build, one rollback	own pipeline and version per service; coordination for cross-cutting changes
Data consistency	transactions in one database	distributed data; reconciliation via events, sagas and eventual consistency
Scaling	the whole application horizontally; parts not separately	individual services scalable independently
Troubleshooting	one stack, one log, one debugger	distributed tracing across several services required
Team autonomy	limited: shared code, shared release	high, provided the domain boundaries are stable
Operating effort	low to medium	high: more infrastructure, networking, monitoring and security per service
Local development	simple	more involved: several services, test data, mocks
Suited to	one team or a few teams, products under construction	several independent teams, very different requirements per area

The monolith is nothing to be ashamed of

A clearly layered monolith with clean module boundaries is the most cost-efficient starting point for many products. There are solid reasons for this:

• Simple deployments: one build, one release, one rollback.
• Traceable transactions: changes across one database stay consistent without distributed coordination.
• Focused troubleshooting: logs, metrics and debugging concentrate on one stack.
• Lower operating effort: less infrastructure, less networking, fewer moving parts.

The word “modular” matters. A monolith without internal structure turns into a hard-to-maintain tangle over time. Even large technology companies have publicly described merging individual services back together because the operating effort outweighed the benefit – a sign that this is not a matter of belief but of weighing trade-offs.

How to keep a monolith modular

• Cut modules by business domain, such as users, orders and billing – not by technical layers
• Allow access to a module only through its defined public interface
• Separate tables or schemas per module and write no queries across module boundaries
• Architecture tests in the pipeline that flag forbidden dependencies – for example with ArchUnit, Deptrac or dependency-cruiser
• Model side effects between modules through internal events instead of direct calls

When microser­vices make sense

Services play to their strengths when organization and requirements call for it. Software architecture often mirrors the communication structure of the organization (Conway's law). When several teams work on one codebase and must constantly coordinate, a split can relieve them. Typical signs:

• Several teams are supposed to develop and release independently of each other.
• Areas have very different release cycles, for example a pricing module that is adjusted constantly and a CMS front end that rarely changes.
• Individual functions must scale much more than the rest.
• A compute-intensive component needs a different programming language or runtime.
• Domains have different availability and service-level requirements.

The costs of distributed systems

Microservices do not come for free. Distributed transactions require patterns such as sagas or accepting eventual consistency, and messages must be processed idempotently. Network calls bring latency and new sources of error. Monitoring, tracing, service discovery and deployment automation become mandatory. Every interface between services needs a stable contract and versioning – our article on REST APIs with OpenAPI shows how that works. Local development and testing also get harder when several services have to run for one test. Without a mature DevOps practice, a “distributed monolith” quickly emerges: services that can only be changed and released together – with the drawbacks of both worlds.

A rule of thumb from practice: before you carve out services, you should be able to build, test, monitor and roll back a monolith in an automated way. If that does not work there, it will not get easier in a distributed setup.

A decision aid in five questions

1. Team structure: Are there several teams that block each other during releases?
2. Scaling: Must one part of the system scale independently and much more?
3. Service levels: Do domains have different availability requirements?
4. Operations: Do you have the skills and tools for distributed systems?
5. Domain boundaries: Are the domains stable enough to separate them for good?

If the answer to the first three questions is mostly “no,” a modular monolith is generally the better choice. Question five is the brake on hasty decisions: if you do not yet know the domain boundaries, you will inevitably cut them wrong – and wrongly cut services are more expensive to correct than modules in a monolith.

Three common miscon­cep­tions

“Microser­vices auto­mati­cally scale better”

Scalability comes from clean architecture, caching and suitable data storage – not from splitting into services alone. A well-built monolith can also be scaled horizontally by running several instances behind a load balancer. How to find bottlenecks before you change the architecture is covered in Cloud scaling for platforms.

“Services will make us faster”

That is only true if teams can actually work independently. If three services have to be changed and released in a coordinated way for every new feature, speed drops instead of rising.

“You can never take a monolith apart again”

With clear module boundaries and the right approach, it is perfectly possible. What matters is that the internal structure is maintained from the start and not sacrificed to deadline pressure.

From monolith to services: the strangler pattern

When the need grows, a module can be extracted deliberately as a service. This step-by-step approach, often called the strangler pattern, lowers the risk considerably because the existing system keeps running while individual parts are replaced. In practice, this sequence has proven itself:

1. Choose a candidate: an area with its own scaling, release or availability needs and clearly delimited data, such as image processing, an import service or synchronization for a mobile app.
2. Define the interface: specify an API contract or events and first encapsulate the module in the monolith behind this interface.
3. Separate the data: own tables or database for the service, with deliberate planning of synchronization. This is usually the most laborious step.
4. Redirect traffic gradually: via a proxy or feature flag, running both in parallel at first and comparing results.
5. Remove the old code: only once the service runs reliably, delete the original part in the monolith.

How you decide what to tackle first in existing systems also depends on legacy burdens. A method for assessing them is shown in our article Prioritizing technical debt.

Practical examples and checklist

Two scenarios from mid-sized companies

Example 1: customer portal. Suppose a service provider builds a portal with user management, order data, documents, billing and interfaces to third-party systems. A small team develops it as a modular monolith with clear module boundaries. A year later a mobile app with offline capability is added. Its synchronization generates different load peaks and changes more often than the rest. Now a dedicated synchronization service pays off – the rest of the portal remains unchanged.

Example 2: grown industry software. Three teams work on a monolith, releases only happen jointly and require laborious coordination. Here the solution does not start with services but with module boundaries and architecture tests in the existing code. Only once an area – for example price calculation – is cleanly separated and needs its own release rhythm is it extracted using the strangler pattern.

Checklist before you decide

• Business domains and their boundaries are described.
• The team and release structure for the coming years is foreseeable.
• Scaling and availability requirements are known for each area.
• The monolith can be built, tested and rolled back automatically.
• Operational skills for monitoring, tracing and automation are available or planned.
• The total cost of development and operation has been roughly estimated for both variants.

How Nano Concepts can help

For new applications for mid-sized companies – such as portals with user management, data maintenance and interfaces to third-party systems – we generally recommend the modular monolith as a starting point. A standalone service is only worthwhile once an area demonstrably has different requirements. We support you with the architecture decision as part of technology consulting, implement new applications in software development and guide existing systems step by step into a sustainable structure through software modernization. In a free initial consultation, we clarify which architecture fits your team and your goals.