Choose microservices when independently deployable boundaries create measurable value in ownership, scaling, resilience, compliance or technology—and when the organisation can operate a distributed system.

Choose a modular monolith when one deployment and simpler data model let the team learn and deliver faster without blocking independent work.

The wrong architecture is the one whose coordination and operating cost exceeds the problem it solves.

Correcting the debate

A monolith is a deployment shape, not a synonym for poor code. A modular monolith can enforce domain boundaries inside one deployable system.

Microservices are not automatically scalable, resilient or modern. Poorly separated services create a distributed monolith: multiple deployments with tight synchronous coupling, shared data and coordinated releases.

Decision 1: Deployment independence

Use services when teams must release materially different domains independently and coordinated deployment is an established bottleneck.

Ask how often releases block, whether architecture or process causes it, whether extraction removes dependency and whether contracts remain compatible.

Decision 2: Ownership

A service boundary needs accountable ownership. If five services require the same three people for every change, distribution has not created autonomy.

Align boundaries with durable business capabilities, not temporary teams or database tables.

Decision 3: Scaling

Services let selected workloads scale separately. A monolith can also scale horizontally. Measure CPU, memory, database, queue and external-service bottlenecks before splitting.

Decision 4: Reliability

Networks add latency, timeouts, retries and partial failure. Define timeout, retry budget, idempotency, degraded modes, dependency objectives, observability and recovery ownership.

A service that cannot function when any dependency fails may provide little isolation.

Decision 5: Data

A modular monolith can use strong local transactions. Independent services require explicit data ownership and often asynchronous coordination.

Avoid shared-database services presented as independent architecture. Design consistency from business requirements.

Decision 6: Security and compliance

Services can isolate sensitive domains but also expand identities, endpoints, secrets, policies and logs. Separate only when the control benefit is explicit and operable.

Decision 7: Technology

A service may justify a different language or store when its workload requires it. Polyglot architecture increases hiring, patching, tooling and support complexity.

Decision 8: Cost and cognitive load

Include platform engineering, CI/CD, discovery, API governance, observability, on-call, environments, network, incidents and onboarding.

Architecture should reduce total friction, not maximise modern components.

When a modular monolith is stronger

Product boundaries are changing. Few teams own the system. Independent scaling is unnecessary. Strong transactions simplify workflows. Operational capacity is limited. Learning speed matters.

Use modules, explicit interfaces, dependency rules, domain ownership, contract tests and observability.

Signals for service extraction

One domain needs different scaling. A team is persistently blocked. Failure isolation has measurable value. Regulation requires separation. A component has a distinct lifecycle. Data ownership can be explicit. Operations can support it.

These are investigation signals, not automatic instructions.

Extraction method

Establish measurements. Select a bounded domain and owner. Define contract and data ownership. Add observability. Create compatibility. Migrate one workflow. Rehearse failure and rollback. Measure improvement. Continue only with evidence.

The strangler pattern can reduce big-bang risk but still requires careful data and routing decisions.

Architecture scorecard

Score independent change frequency, scaling difference, isolation value, security separation, data separability, ownership, operational readiness and migration risk.

High value with low data separability is a design problem, not a simple extraction.

A low-risk architecture decision process

Map pressure before choosing a pattern

Identify where deployment coupling, ownership conflict, scaling, reliability or compliance creates measurable cost. If pressure is only hypothetical, improve modularity and observability before introducing distributed operations.

Define an extraction boundary

Choose a capability with clear ownership, stable contracts and limited transactional coupling. Specify data authority, failure behaviour, compatibility, observability and rollback before moving code or data.

Run the decision as an experiment

Measure release independence, lead time, incident load, cloud cost and cognitive overhead before and after extraction. Continue only when the operational benefit exceeds the new coordination and reliability burden.

Start with organisational pressure

Architecture should answer a demonstrated constraint. Map deployment delays, ownership conflicts, scaling hotspots, incident blast radius, regulatory boundaries and rate of change. If the pressure is hypothetical, improve modularity, tests and observability before distributing the system. Microservices exchange code-level coupling for network, data and organisational coordination.

Evaluate the proposed operating team, not only the target diagram. Independent services require ownership, deployment, monitoring, incident response and lifecycle maintenance. A small team with many services often spends more time coordinating and operating than delivering product outcomes.

Design a modular monolith deliberately

A modular monolith is one deployable system with explicit internal boundaries. Organise capabilities around business ownership, restrict cross-module access and expose stable interfaces. Keep data rules near the owning module even when tables share a database. Architecture tests and code ownership can prevent convenient shortcuts from eroding boundaries.

This pattern retains simple transactions, local debugging and lower operational overhead while preparing future extraction. It is not an excuse for a layered codebase in which every module reaches every table. Measure coupling and require decisions for new cross-boundary dependencies.

Data is the hardest boundary

A service should own its data and expose behaviour through contracts, but extracting data requires more than moving tables. Identify invariants, reporting joins, historical corrections and workflows that currently depend on one transaction. Decide where eventual consistency is acceptable and how users see intermediate states.

Use patterns such as outbox events, change capture or explicit synchronisation only when their failure and recovery behaviour is understood. Define idempotency, ordering, replay, retention and reconciliation. A distributed system without a reconciliation process eventually turns operational errors into unexplained business discrepancies.

Reliability and observability

Network calls fail differently from local calls. Every dependency needs timeouts, bounded retries, load shedding and a decision about fallback. Prevent retry storms and cascading failure. Define service objectives around customer journeys and allocate responsibility where multiple services contribute to the result.

Standardise logs, metrics, traces, correlation identifiers and deployment metadata before increasing service count. Operators should follow a request across boundaries and identify the responsible release. Observability added after extraction leaves teams with more failure modes and less ability to explain them.

Security and platform requirements

Each service introduces identity, secrets, dependencies, network exposure and access policy. Use service identity, least privilege, managed secrets and consistent patching. Do not assume an internal network is trusted. Data classification and regulatory boundaries may justify separation, but controls still need evidence.

A platform should provide paved paths for repositories, builds, deployment, configuration, monitoring and incident response. Without this, every team builds a partial platform and security becomes inconsistent. Platform investment is part of the microservices cost and should be justified by repeated demand.

Cost and cognitive load

Compare infrastructure, data transfer, observability, build systems, developer environments, testing, on-call and coordination. Cloud cost is only one component. Track lead time, deployment frequency, change failure, recovery time and incident handoffs before and after a change. Architecture is successful when business and engineering outcomes improve.

Service count is not a maturity metric. Prefer the smallest number of independently operated components that addresses real constraints. Consolidate services when boundaries no longer justify their operational tax. Reversibility should include the option to merge as well as extract.

A safe extraction sequence

Choose a capability with clear ownership, limited transactional coupling and measurable pressure. Define its contract, data authority, failure behaviour and rollback. First enforce the boundary inside the monolith, add tests and observe calls. Then duplicate or migrate data with reconciliation before shifting a small amount of traffic.

Keep the old path available until business outcomes and operations are stable. Measure release independence, latency, incident load, cost and developer cognitive burden. Continue extraction only when benefits exceed the new coordination cost. One successful service does not prove the rest of the monolith should be divided.

Architecture review checklist

Document business capabilities, module or service owners, deployment dependencies, data authority, synchronous calls, events, failure behaviour and security boundaries. Measure lead time, release coordination, incident handoffs, scaling hotspots and platform effort. Separate current evidence from expected future demand.

For every proposed service, ask which constraint it removes, which team will operate it, what data it owns, how calls fail, how changes remain compatible and how the system reconciles errors. Estimate platform, observability, testing and on-call work. Define rollback and the option to merge the service later. Approve extraction only when a bounded experiment can prove improvement in independence, reliability or cost.

Migration patterns and anti-patterns

A strangler approach routes a bounded capability to a new component while the monolith continues serving the rest. It works when routing, data ownership and rollback are explicit. Branch by abstraction can replace an internal implementation behind a stable interface before any network split. Both patterns reduce simultaneous change and allow evidence to accumulate.

Avoid extracting shared utility code as a service merely because many modules use it. A remote shared service introduces availability and version coordination without clear business ownership. Also avoid one service per database table or per development squad. Boundaries should follow cohesive capabilities, transaction needs and operational accountability rather than organisational fashion.

Shared databases can be a temporary migration stage, but unrestricted cross-service table access preserves coupling and makes ownership ambiguous. Limit new access, record a transition plan and expose behaviour through the owning boundary. When data must be duplicated, define source authority, propagation, reconciliation and deletion. Do not hide distributed consistency behind a generic event bus.

Treat contracts as products. Version deliberately, test consumers, observe usage and provide a deprecation path. Use synchronous calls only when the user journey requires an immediate answer; asynchronous events should represent facts that already occurred and support replay safely. The goal is not maximum messaging—it is change independence with understandable failure.

Finally, schedule a post-extraction review. Compare the original pressure with measured results and include incident burden, platform work and developer experience. If the service did not improve independence, reliability, scale or compliance, improve the boundary or merge it. Architecture governance should reward better outcomes, not permanent complexity.

The architecture decision record

Conclude with the chosen pattern, evidence, rejected alternatives, assumptions and review triggers. State which business pressures the decision addresses, who owns each boundary and what platform capability is required. Include expected effects on deployment, reliability, scale, security, cost and team cognition. Revisit the record when organisational structure, traffic, regulation or product boundaries change. Architecture is a continuing economic and operating decision, not a one-time declaration of monolith or microservices.

Use architecture fitness functions where valuable: automated checks for dependency direction, contract compatibility, ownership metadata, security policy and deployability. Pair them with periodic human review of business boundaries and operational burden. Automated rules keep agreed constraints visible, while review prevents yesterday’s architecture from becoming permanent dogma after the product and organisation change.

Scenario: extracting one capability from a growing SaaS monolith

A SaaS team experiences release coordination and scaling problems around report generation. The rest of the product changes predictably, but large reports consume resources, retry unpredictably and delay deployments owned by another team. Instead of dividing the whole application, the architecture review selects reporting as a bounded experiment because it has measurable pressure, a potential owner and work that can run asynchronously.

The team first creates a module boundary inside the monolith. Requests use one interface, report status has explicit states, and tests capture permissions and lifecycle rules. An outbox records accepted jobs reliably with the existing transaction. Workers process jobs idempotently and store outputs in an owned location. The user-facing application can display queued, running, completed and failed states without waiting for a long network request.

Observability follows a report from request through queue, processing and delivery. Timeouts, retry limits, dead-letter handling and reconciliation are defined. The new component receives service identity and only the data required for the job. Deployment begins with internal customers and a reversible route; the old implementation remains available until output equivalence, latency, cost and recovery meet acceptance.

After launch, the review compares release independence, incident load, cloud cost, lead time and team cognition with the baseline. If reporting improves while platform burden remains acceptable, the boundary is retained. That result does not justify extracting billing, identity and every other module. The value comes from resolving a demonstrated constraint with the smallest independently operated component, while preserving the option to merge it later.

Questions for an architecture review partner

Ask the partner to begin with measured organisational and product pressure rather than a target diagram. Require maps of ownership, deployment coupling, data authority, transaction boundaries, synchronous calls, events, incidents and platform capability. For every proposed service, ask which constraint it removes, who operates it, how it fails and how errors reconcile. The review should compare a disciplined modular monolith, selective extraction and broader distribution using the same outcome criteria. Include infrastructure, observability, testing, on-call and cognitive cost rather than cloud compute alone. Request a bounded experiment with baseline measures, acceptance and rollback. A strong reviewer will recommend keeping or merging components when independent operation lacks value. Confirm how contracts, data migration, security identity and compatibility will be governed after the initial project. Architecture advice is useful when it produces reversible decisions and an operating model; a polished service map without accountable teams and failure behaviour is only illustration.

Include organisational readiness in the final recommendation. Independent services need teams with authority, operational capacity and stable boundaries. If ownership is shared or frequently changing, improve the modular monolith and platform foundations first. Reassess when the organisation can support independent lifecycle responsibility. Architecture should fit how the company actually makes decisions, not an idealised future org chart.