Microservices or Modular Monolith?

When designing a new webshop, order management, or manufacturing integration system, the question of "microservices or modular monolith" is rarely just a technological debate. The choice will affect the speed of releases, error traceability, operational load, integration reliability, and how well the system aligns with the company's actual operations. A poorly timed architectural decision may not cause immediate problems but can embed itself into development and operational costs for years.

System boundaries are more important than the technological label

The two approaches are often oversimplified. Monoliths are described as outdated, hard-to-modify systems, while microservices are seen as automatically scalable, modern target states. This is misleading. A well-constructed modular monolith can be a transparent, testable, and sustainable business system in the long term. Similarly, an unnecessarily fragmented microservices environment can pose lasting risks with network errors, data synchronization, and many separate deployment units.

The real question is where the natural boundaries of business processes lie. For example, order processing can link inventory reservation, pricing, billing data transfer, logistics organization, and customer communication. If these steps form a tight business transaction, early separation can significantly increase complexity. However, if they change at different rates, are managed by different teams, or have different availability and load requirements, separation may have a business justification.

The architecture should serve verifiable operations, not organizational fashion. The goal is not to have the most components possible, but to quickly determine what happened, where it happened, and how to restore the process in a controlled manner in case of an order error, a late supplier data arrival, or an ERP connection outage.

When is it advisable to start with a modular monolith?

A modular monolith is a single deployable application where functions are organized into clearly separated business modules. Examples include product catalog, order management, warehouse processes, partner integrations, or access management. The application runs as a unit, but the modules have their own responsibilities, data management rules, and well-defined internal interfaces.

This is an especially good starting point for mid-sized enterprise systems where multiple internal and external processes need to be unified, but the development and operations organization does not yet justify dozens of independent services. For an order and logistics platform, for example, data consistency, process traceability, and rapid business adaptability are often more important than running every function in a separate container.

The advantage of a modular monolith is that transaction handling is simpler, fewer systems need to be crossed for debugging, and the deployment chain is easier to oversee. Business rule interactions can be managed in a single versioned release. This does not mean that the system should become a disorganized code mass of shared database tables. On the contrary, module boundaries must be disciplined from day one.

The approach's limitation becomes visible when a functional area receives very different loads, develops in separate life cycles, or coordinating releases becomes disproportionately slow. In such cases, the entire system does not need to be rewritten; instead, it should be examined which modules are mature for separation.

When are microservices justified?

A microservices architecture provides real advantages when independent services are both business-wise and operationally autonomous. A service has clear responsibilities, its own interface, preferably its own data management ownership, and a separate deployment process. It is not merely about placing parts of an existing application into separate processes or containers.

It may be justified, for example, to separate a high-traffic product and pricing information service if it is used differently by webshops, B2B portals, marketplaces, and internal sales systems. Similarly, a carrier integration layer that communicates with multiple providers and requires its own retry, logging, and processing rules can be an independent area. In these cases, separate scaling, independent releases, and targeted error handling can create tangible business value.

However, the cost is significant. Network communication between services can fail or delay. What was previously a simple database transaction becomes messaging, event processing, repeated processing, and sometimes temporarily differing data states. Service identification, access regulation, central logging, metric collection, alerts, configuration management, backup, and version compatibility must be solved. These are not supplementary tasks but part of the architecture.

Microservices or modular monolith: what evidence should guide our decision?

The decision should be derived from actual operations, not assumed future size. The fact that a company wants to grow does not in itself necessitate microservices. Growth often requires clean master data, reliable integrations, consistent access models, and measurable processes first.

First, it is necessary to identify which business areas change frequently and independently. If every modification in warehouse logic requires a full release of the customer portal, billing, and pricing, the boundaries are likely too tight. However, if functions typically change as part of a business process, separate deployment may bring more coordination than advantage.

Second, data ownership must be examined. Many architectures become difficult to manage because multiple services directly modify the same order, customer, or inventory data. In microservices, every critical data object needs a clear owner. Other systems can request data or initiate processes through interfaces or events. This requires greater discipline but makes responsibility more predictable.

Third, operational maturity must be realistically assessed. Is there unified logging and monitoring? Can a business transaction be traced across multiple systems? Are secrets and accesses securely managed? Are test and release processes automated with rollback options? If these are not yet established, it is advisable to strengthen the foundations before introducing microservices.

Gradual separation generally carries less risk

Architecture is not a one-time, final decision. A disciplined modular monolith is suitable for later targeted separation of functions where independence needs are proven. In a gradual approach, stable internal module boundaries, documented interfaces, and separated responsibilities are established first. Then a specific, high-value area—such as partner data transfer or notification processing—can become an independent service.

Separation should be tied to measurable problems. These can include persistently different load profiles, frequent and independent business changes, special technological requirements, or isolating errors in an external integration. "It will scale well someday" is not a sufficient reason if daily operational transparency deteriorates in the meantime.

In many cases, a hybrid solution is best. Central business processes remain in a modular monolith, while asynchronous, high-volume, or areas with intensive external system communication operate as separate services. This is particularly relevant for ERP, webshop, warehouse, and carrier system integrations, where the reliability of external connections and reprocessing management require independent attention.

Operability as a design requirement

Regardless of the chosen model, operational requirements must be defined during the design phase. A business-critical system must handle faulty or missing messages, repeated processing, access logging, backup, capacity monitoring, and controlled releases. These are not just infrastructure tasks; they directly affect order fulfillment, inventory data accuracy, and the precision of financial processes.

In CGAT's approach, selecting an architecture begins with business process assessment, identifying integration boundaries, and clarifying operational requirements. The value of a system is not determined by the number of services it comprises, but by how it serves the company in a controllable, sustainable manner that aligns with daily operations even amidst changes.

Before the next development decision, it's worth asking not which architecture sounds more modern, but which structure will make critical business processes more interpretable, modifiable, and operable a year from now.