Monolith or microservices: choose around business needs

A meeting about a new customer portal quickly turns into a discussion of microservices. Nobody has yet established which parts of the business change together, who will operate the system or where demanding workloads will occur. Even so, the architectural label can sound like a promise of quality. A monolith or microservices decision becomes useful only when it fits the way the business will develop and run the product.

This is more than a choice about appearing modern. It affects releases, information flow, incident investigation and coordination between teams. Discuss the operational responsibilities an approach introduces alongside the benefits it might offer. For the business, the first question is which need must be served, rather than how many technical pieces the application should contain.

Clarify the distinction behind the labels

A monolithic application generally runs its main behaviour within a single deployment unit. That does not require disorganised code. Customer management, orders and reporting can be arranged as modules with clear responsibilities. Keeping internal boundaries understandable allows a single deployment to remain different from an application in which every part depends unpredictably on every other part.

A microservices approach divides business capabilities into services that can run and be released separately. This is not simply a matter of creating more folders. Communication and ownership of information need deliberate treatment. The ability to change one part independently comes with coordination work. Services that constantly require simultaneous changes may offer less practical independence than the diagram suggests.

Begin by discussing the need for change rather than drawing boxes. Which area changes most often? Who owns it? Does one capability genuinely have a different capacity requirement? Without answers, a detailed deployment design can turn poorly understood business boundaries into infrastructure decisions that are expensive to revisit. The terminology should help explain the reasoning instead of replacing it.

User count cannot select an architecture by itself

“We expect many users” does not describe a workload. Concurrent activity, record sizes, query behaviour and the response time of connected systems all matter. A portal with many infrequently used accounts may encounter different constraints from an application where a few people produce demanding reports. Explain the usage scenario behind any capacity assumption.

Splitting an application before identifying a performance bottleneck may leave the original problem intact. An inefficient query or a slow external request can remain slow in a new arrangement. Test with representative activity and realistic information. Define acceptable behaviour for the important task so the technical alternatives can be assessed against the same requirement.

Capacity planning should not depend on a single prediction of future growth. Establish the near-term need, the indicators to observe and the conditions that would trigger reconsideration. The business can remain prepared for change without accepting unnecessary operational work for a workload that has not materialised. Architecture should remain a reasoned decision that can be reviewed as circumstances change.

Technical independence needs an ownership model

Separately running services still need owners. Without them, changes and incidents can lead to confusion about responsibility. Each service requires a workable approach to development, verification, deployment and monitoring. A small team can run several services, but increasing the number of components does not eliminate the work involved in keeping them useful and reliable.

If independent releases are a goal, examine how often a change crosses boundaries. When adding one field requires every service to be updated on the same day, the chosen boundaries may not deliver the expected flexibility. Compatibility and transition behaviour need attention. The business outcome is whether the arrangement supports more dependable change, rather than whether components have different names.

For one delivery team, a well-organised modular application may provide a straightforward starting point. Multiple teams owning clear business areas may have different needs. Neither observation is a universal rule. Consider experience, existing infrastructure and uncertainty about the product together. Headcount alone is not enough information to justify a design or dismiss an alternative.

Unclear data ownership makes service boundaries difficult

Imagine a fictional maintenance company where approving a quotation creates a job and an estimated materials requirement. Quotation, operations and inventory capabilities use related information for different purposes. If they are separated, decide which part owns each record and which source is authoritative. Allowing several places to change the same information without clear rules can produce conflicting results.

Discuss partial failure as well as the successful path. If the quotation is approved but the job has not yet been created, what does the user see? Could a retry create the job twice? How is an unresolved state found and investigated? Separation can make these questions more prominent, but acceptable behaviour depends on the business process rather than an architectural preference alone.

Ask whether every step truly needs to complete together immediately or whether a controlled delay is acceptable. That answer can affect the design. Leaving users unaware of unfinished work differs from deliberately designing a visible pending state. A behaviour that appears to follow from a technical approach should still be a choice the business understands and accepts.

Separation does not automatically contain every failure

Dividing services does not guarantee resilience. If a main operation waits for every other service on each request, one unavailable component may still have a wide effect. Timeouts, retries, pauses and queued work need to reflect the intended behaviour. Unrestricted retries can add pressure to an already struggling dependency rather than improve recovery.

Some workflows can tolerate a temporary alternative. An application might retain a record safely while showing that its notification has not yet been sent. Continuing past a failed payment or permission check may be inappropriate. Decide which operations stop under which conditions. These are business consequences that should not be left to an undocumented engineering assumption.

Test the proposed failure behaviour in a controlled environment. Observe what happens when a connection is unavailable, a response is late or the same message arrives again. The purpose is to establish that users and records experience an acceptable result. An impressive infrastructure demonstration is less valuable than evidence that the application handles the conditions the business actually cares about.

Compare running costs as well as build costs

More deployment units can change the monitoring and diagnostic work. Investigators need to connect the steps of a user action to understand where it became delayed or failed. Configuration, access credentials and versions require management too. Managed infrastructure can simplify some tasks, but it does not remove the need to decide who is responsible for the overall service.

A monolith also requires operational work. Updates, database administration, backups, permissions and capacity still matter. The comparison is not between a system that needs operating and one that does not. Identify which duties each option creates, which team performs them and how they are funded. Ownership cost extends beyond the initial development invoice.

Consider transferability as well. The business should understand its accounts, deployment approach and dependence on individual knowledge. Having another authorised team run the application from the documentation provides a useful check. An architecture that only one person can explain may be difficult to sustain, whatever its formal style. Handover conditions belong in the evaluation rather than being postponed until someone leaves.

Replacing everything is not the only migration route

Where a current application’s difficulty is concentrated in one area, consider whether that area can be separated. A demanding reporting capability or a clearly bounded external connection may justify a different arrangement once its boundaries are understood. Assess the data flow and operational effect. An existing system does not automatically need a complete rewrite simply because it has become inconvenient to change.

Plan how old and new behaviour will coexist. Which system provides each record, how will consistency be checked and which step can be reversed if necessary? If employees must use two places temporarily, describe the additional work, expected duration and owner. Migration itself consumes effort and should appear in the plan instead of being treated as a free consequence of the new design.

Evaluate the result against the problem that prompted the change. The aim might concern release coordination, the effect of incidents or the load created by a particular task. Agree the evidence needed for that review. A technology change does not establish success by itself. Examine whether the targeted operating conditions actually became more manageable after the transition.

Record alternatives and the conditions for another review

Keep a short decision record containing the chosen approach, alternatives considered, important assumptions and accepted limitations. Future team members can then understand the context. If the conditions change, the decision can be reconsidered without defending or rejecting the earlier approach purely because of its label. The record should preserve reasoning, not simply announce a winner.

Where business boundaries and change patterns remain unclear, the discovery stage of a custom software project can produce examples that inform the architecture. The aim is to agree a system that supports real work, can be operated by the available team and can be changed when needed. The number of technical components is not a useful success measure on its own.

A final review can ask practical questions in plain language. Can the team explain a release from preparation to verification? Can it locate an interrupted user action? Does the business know which limitations it is accepting? Can the data be recovered through a documented process? Answers to those questions make the design easier to assess than a debate based entirely on architectural terminology.

Frequently asked questions

Does a monolith necessarily use old technology?

No. Deployment style and the age of the tools are different matters. An application built with current tools can still be released as one unit. Code organisation, business boundaries, verification and the ability to operate the product appropriately are more informative than assuming that a single deployment means an obsolete system.

Do microservices automatically improve performance?

No. Running selected capabilities with separate capacity may help in some situations, but communication and data design introduce their own costs. Dividing the application without measuring the current bottleneck may leave it unresolved. Assess the approach through representative work and the behaviour required by the business, rather than assuming that separation makes every task faster.

Can a small team use microservices?

Yes. Team size alone does not settle suitability. Experience, service count, operational tools and clear ownership all matter. The team needs a realistic plan for monitoring, releases and incident response as well as development. The important question is whether those responsibilities are sustainable alongside the business’s ongoing product priorities.

Can a modular monolith be split later?

Carefully managed boundaries and dependencies can make it easier to discuss separating particular areas. That does not make extraction automatic or free. Information ownership, communication and migration behaviour still require work. A modular arrangement can provide a clearer foundation for future options without promising that every possible transition will be simple.

Should the business manager choose the architecture?

Qualified technical people should assess the options, while the business explains priorities, budget, tolerance for interruption and expectations about change. The decision draws on both kinds of information. A manager does not need to know every technical term, but should understand the practical consequences and accepted limitations before approving the proposed approach.