Monolith or Microservices? Why Business Context Matters More Than Architecture Fashion

Distinguish three models

An unstructured monolith mixes responsibilities; a modular monolith has one deployable unit with enforced domain modules; microservices run and deploy separately and usually own their data.

Use a decision matrix

Compare domain stability, team autonomy, release cadence, scaling asymmetry, isolation needs, data consistency, platform maturity, and support capacity. Choose the simplest option that meets evidence-based constraints.

Account for distributed cost

Independent services require contracts, retries, tracing, service identity, secrets, deployment automation, incident ownership, and distributed-data decisions. These costs exist before business value appears.

Build a monolith that preserves options

• Organise by business capability.
• Enforce module interfaces.
• Keep ownership clear.
• Prevent direct cross-module data access.
• Automate tests and deployment.
• Measure reasons before extracting a service.

Composite example: B2B sales platform

Keep catalogue, pricing, orders, and fulfilment modular in one deployable system until scale, ownership, or isolation creates a proven reason to extract one capability.

When to reject a microservices migration

Reject it when boundaries are unclear, one team owns everything, delivery is not automated, observability is weak, or the proposal solves code organisation rather than independent operation.