Modular monolith or microservices: how to choose

Ask the right architectural question

The choice is not between modern technology and outdated technology. It concerns product boundaries, team organization and operating constraints. A monolith can be well structured and a microservices architecture can remain tightly coupled. Start with the needs: who modifies each part, how often should it be deployed, and what loads should scale separately? A decision made without this information risks shifting complexity to network, data, and deployments without solving a concrete problem.

Understanding the modular monolith

A modular monolith ships as a single application, but its functionality has explicit boundaries. Customers, orders and billing can expose internal contracts and protect their details. Common deployment simplifies certain transactions and operations. However, dependencies must be monitored: if all modules read all tables directly, the borders become decorative. Document responsibilities and authorized access. Modularity is not achieved simply by creating folders; it assumes that changes remain localized and that important rules have an identifiable owner.

Understand what a microservice makes independent

A microservice seeks functional and operational autonomy. It must be able to evolve with a clear contract and defined responsibility. If its delivery systematically requires deploying four other services in a specific order, this autonomy is limited. The division into technical layers, with one service for all the controllers and another for all the rules, often produces a lot of calls without real business independence. Prioritize consistent capabilities. The size of the department is less important than the clarity of its responsibility and the ability of its team to operate it.

Compare costs that diagrams forget

A memory call is replaced by a network communication with possible latency, timeout, and unavailability. Authentication between services, observability, contracts, deployments and configuration must be managed. Development and test environments become more difficult to reproduce. However, independent services can provide real value when multiple teams need to move at their own pace. The comparison must therefore include the total cost: development time, operating load, incident frequency and coordination effort. Counting only servers or lines of code gives an incomplete view.

Maintain data consistency

In a single application, multiple writes can sometimes share a local transaction. In a distributed system, ordering, payment and inventory can belong to different departments. A breakdown in the middle of the journey creates a partial state that must be recognized and treated. Events, compensations, and recovery mechanisms can help, but add rules to design. Define what the business accepts as a consistency deadline. A screen should not announce payment confirmed simply because a message has been sent. The expected consistency must be explicit for each critical operation.

Example: a growing reservation product

Initially, a small team builds booking, customers and billing into a modular application. Internal contracts are defined and the rules are tested. Later, sending notifications experiences significant load and must scale independently. Extracting this capacity can be useful if the messages, responses and responsibilities are well identified. There is no need to check out all modules at once. The migration must preserve the identifiers and avoid double sendings. This progressive trajectory reduces risk compared to a global rewrite driven solely by a target architecture blueprint.

Design compatible contracts

Services and customers do not always change at the same time. Define formats, required fields, errors, and version compatibility. For events, specify their business significance: a request received is not an order definitively accepted. Avoid having consumers depend on internal table details. Contract tests can detect certain ruptures, but must be supplemented by business pathways. An added field is often easier to make compatible than a silent change in meaning. The documentation must explain the guarantees actually offered.

Align architecture with team capacity

A team must be able to understand, deliver and monitor what they have. Creating ten services for two developers can increase downtime and reduce time spent on the product. Conversely, multiple teams can suffer from a single deployment that requires ongoing coordination. Analyze human responsibilities and dependencies as much as technical components. Operations, safety and automation skills factor into the decision. An architecture is only sustainable if the organization has the means to maintain it, including during a breakdown and the departure of a key person.

Make a documented and reversible decision

Write a short decision that describes context, options, choices and consequences. List the assumptions: expected load, number of shifts, availability level and separation requirements. Define signals that will warrant reassessment, such as regularly blocked deliveries or capacity that cannot be scaled with the rest. It is not necessary to predict all future developments. It is more helpful to keep clear boundaries and relevant tests to make changes possible. An architectural decision must be able to be explained by a need, not just by a technical preference.

Evolve without increasing complexity

Start by measuring existing problems: dependencies, delivery times, incidents and cost of changes. Improving the model, tests or queries can solve the need without extracting services. If separation is warranted, migrate gradually and monitor the entire journey. Tuplify Studio can support the framing of an architecture and develop modular applications or services according to your constraints. The main criterion remains the ability to deliver a reliable and maintainable product. The simplest architecture that meets real needs often leaves more time for users.

Workshop: evaluate a service extraction

Choose a module being considered for extraction and list its data, calls, and dependencies. Ask if his team could actually deliver it without changing the rest. Write down the consequences of a slow call, no answer, and an event received twice. Estimate additional monitoring tools and procedures needed. Compare this cost to the problem at hand: late delivery, special charge or separate liability. If the benefit remains unclear, improve internal boundaries first. This evaluation may reveal that a simple module contract is sufficient, or on the contrary that an autonomous capacity provides a specific gain justifying distributed communication and its exploitation.

Frequently asked questions: performance and evolution

Are microservices always faster? Communications add latency, but sometimes allow targeted scaling. Performance must be measured over the entire course.

Does a monolith prevent you from growing? A modular application can serve many purposes. The limits depend in particular on the model, access to data, operation and organization.

Can we change later? Yes, but the ease depends on the borders already present. Protecting a module's data and its contracts makes extraction more affordable. Conversely, moving code to multiple processes without reducing coupling can retain the constraints of the initial system while adding those of the network.