Monolith or microservices: decide from operating constraints

Microservices change the location of complexity.

A large dark module and smaller connected modules beneath an inspection lens.

Microservices change the location of complexity. They can give a bounded capability its own deployment and scaling path, but they also introduce network failures, distributed ownership and operational work. A growing product should compare these costs with a modular monolith before choosing a migration. The number of developers or lines of code alone does not establish a useful service boundary.

Find the pressure that requires separation

Describe a repeated problem: one workload consumes resources needed by another, teams cannot release independently, or a capability needs a different availability boundary. Measure the impact and identify the component responsible. If the real constraint is a slow database query or a coupled product approval process, replacing function calls with HTTP calls may preserve the problem while adding another failure mode.

Test the boundary inside the application

Give the candidate module explicit interfaces and ownership before extracting it. Check whether other modules write directly to its tables or require one transaction across the proposed boundary. Define who owns the data and how consumers receive changes. A module that cannot be described without exposing its internals is unlikely to become a clean service merely because it runs in another container.

Price the operational responsibilities

Include deployment pipelines, identity between services, tracing, dashboards, version compatibility and on-call ownership. Walk through a timeout after the receiving service has committed work: the caller must recover without duplicating the effect. Decide how the system behaves when a dependency is unavailable. Count the recurring effort of those responsibilities, not just the initial extraction estimate.

Choose a reversible first step

Extract a bounded, measurable capability only when its benefit outweighs the coordination cost. Keep a migration plan for existing data and consumers, a comparison period and a rollback boundary. A modular monolith remains a strong option when one team owns the product and shared transactions are valuable. Document the signals that would justify revisiting that choice; an architecture decision can be correct today without being permanent.

Compare the full cost of two options

Model implementation, migration, recurring operations and exit costs over the same horizon. Enter your own quotes and assumptions for each option.

Horizon (months)CurrencyAnnual discount rate (%)

Option A

Implementation costMigration and onboardingMonthly platform / hostingMonthly maintenance / supportAnnual recurring cost increase (%)Initial contingency (%)Exit cost at the end

Option B

Implementation costMigration and onboardingMonthly platform / hostingMonthly maintenance / supportAnnual recurring cost increase (%)Initial contingency (%)Exit cost at the end

Enter all costs for both options. Use 0 for costs that do not apply.

Your inputs are planning assumptions, not market prices. Contingency applies to implementation and migration only. Recurring costs increase every 12 months; exit cost occurs at the end. Discounting assumes month-end payments. Taxes, revenue, financing and currency conversion are excluded. Cost crossing is not a return-on-investment forecast.

Frequently asked questions

Are microservices automatically more scalable?

No. Independent scaling helps only when a separable workload is the bottleneck and shared dependencies can support it.

Can a monolith have clear ownership?

Yes. Modules, interfaces and explicit data ownership can create strong boundaries within one deployment.

Should every service have its own database?

Define data ownership first. Independent storage introduces consistency and migration questions that must be designed deliberately.

What is a useful first extraction?

A capability with a clear contract, measurable pressure and an operating team able to support it.

Can we reverse the decision?

Sometimes, but data ownership and consumer contracts make reversal costly. Plan migration and exit paths before extracting.

Bring the scope. We will help make it buildable.

Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.

Explore the delivery scope →