Monolith vs microservices

01Three shapes: monolith, modular monolith, microservices

Think of a restaurant. A monolith is one kitchen where every cook can grab any ingredient from any shelf: fast at first, chaotic later. A modular monolith is the same kitchen split into stations (grill, pastry, salads), each with its own shelves and a counter where orders are handed over. Microservices are separate restaurants that send each other orders by courier: each can open, close or renovate independently, but every handover now takes time and can get lost. In software terms, a monolith is one codebase, one process type and usually one database. A modular monolith keeps one deployable but divides code into modules with public interfaces, and each module owns its tables. Microservices are independently deployable processes, each with its own datastore, communicating through HTTP, gRPC or messages.

• Monolith: simplest to build, test, deploy and debug; risk is a 'big ball of mud'.
• Modular monolith: one deploy, enforced boundaries, in-process calls, one transaction when you need it.
• Microservices: independent deploys and scaling per service; cost is distributed-systems complexity.

02The real costs of microservices

Microservices move complexity from the code into the network. A function call that never failed becomes a request that can time out, arrive twice or succeed without you hearing about it. A single database transaction becomes a distributed workflow that needs sagas, outboxes and idempotency. Data ownership becomes strict: the orders service may not read the customers table, so you need APIs, events or local copies, and those copies can be stale. Debugging needs distributed tracing, correlated logs and per-service dashboards, or a single slow checkout becomes a detective story. Deployment needs CI pipelines, versioned contracts, service discovery and usually an orchestrator. Every service also needs its own monitoring, alerts, secrets and upgrades. None of this is impossible, but it is a permanent tax you pay every week.

• Distributed transactions: no shared ACID transaction across services.
• Network failures: timeouts, retries, partial failures, cascading outages.
• Data ownership: no cross-service joins; duplicated, eventually consistent data.
• Observability and cost: tracing, more infrastructure, more on-call surface.

03Finding boundaries with bounded contexts

The hardest part of any split is where to cut. Domain-Driven Design gives a practical tool: the bounded context, an area of the business where words have one precise meaning. 'Product' in the catalogue means a description with photos; in inventory it means stock in a warehouse; in billing it means a price line. Each context gets its own model and its own module. Good boundaries have high cohesion inside (things that change together live together) and low coupling outside (a narrow, stable interface). A useful test: can a team change this module for a week without coordinating with anyone? If not, the boundary is wrong. Cut by business capability (ordering, payments, loyalty), never by technical layer (a 'database service' or a 'validation service'), which only creates chatty, fragile dependencies.

1// eslint.config.mjs: modules may import each other only through a public index
2export default [
3  {
4    files: ["src/modules/**/*.ts"],
5    rules: {
6      "no-restricted-imports": ["error", {
7        patterns: [{
8          group: ["@/modules/*/internal/*", "@/modules/*/db/*"],
9          message: "Use the other module's public index.ts, not its internals.",
10        }],
11      }],
12    },
13  },
14];

04Building a modular monolith that stays modular

Boundaries that live only in a diagram erode within months. Enforce them in code. Give each module a folder with a public entry point (services, DTOs, events) and keep everything else internal. Let each module own its tables and forbid other modules from querying them directly; cross-module reads go through the owning module's service. Use in-process domain events for side effects ('order paid' triggers loyalty points) so modules do not call each other in long chains. Add lint rules or architecture tests that fail the build on forbidden imports. In frameworks with a module system, such as NestJS, export only what other modules may use. The payoff: when one module truly needs to scale or deploy separately, you already have its interface, its data and its events, and extraction becomes a project of weeks rather than a rewrite.

05Migrating with the strangler fig pattern

When an existing monolith must be split, never attempt a big-bang rewrite: it freezes features for months and usually fails. Use the strangler fig pattern, named after a plant that slowly grows around a tree. Put a routing layer (a reverse proxy or API gateway) in front of the monolith. Pick one well-bounded capability, build it as a new service, and route only its endpoints there while everything else still hits the monolith. Keep data in sync during the transition with events or change data capture, then move ownership of the data to the new service. Repeat one capability at a time, and delete the old code after each step. Each step is small, reversible and shippable, so the business keeps moving while the architecture changes underneath.

• Start with a capability that has clear data ownership and few inbound dependencies.
• Run old and new paths in parallel and compare results before switching traffic.
• Measure: if the new service does not make deploys or scaling easier, stop.

06Choosing: team size, domain and scaling needs

Conway's law says systems mirror the communication structure of the teams that build them. One or two small teams gain almost nothing from microservices, because they coordinate easily anyway, while they pay the full operational cost. Microservices start paying off when several autonomous teams block each other on a shared release, when parts of the system have very different scaling or reliability needs (a video encoder versus an admin panel), or when compliance demands hard isolation. Traffic alone is rarely the reason: a well-built monolith scales horizontally behind a load balancer to very large loads. A sensible default for most companies is to start with a modular monolith, invest in boundaries, tests and observability, and extract a service only when a concrete, measured pain justifies it.

07Coupling you cannot see: temporal, data and deployment

Import rules catch code coupling, but three quieter kinds decide whether a split works. Temporal coupling: service A can only finish its request while B is up, because it calls B synchronously. Availability then multiplies: three services at 99.9 percent each, chained, give roughly 99.7 percent for the whole flow. Data coupling: two modules read or write the same tables, so a schema change in one breaks the other without any import between them. Deployment coupling: a change needs coordinated releases because a contract changed in a non-backward-compatible way. Measure these before splitting. Look at which tables each module touches, at the call graph from tracing, and at which folders change in the same commits over a few months (change coupling from Git history). Modules that keep changing together belong together, whatever the diagram says.

• Chained availability: multiply the SLOs of every synchronous hop.
• Shared tables are a boundary violation even with clean imports.
• Git co-change analysis reveals real coupling cheaply.

08Contracts between services: versioning and consumer-driven tests

Once a boundary becomes a network boundary, its interface is a published contract and independent deployment depends on keeping it stable. Follow the tolerant reader rule: consumers ignore fields they do not know, producers only add optional fields. Breaking changes go through expand and contract: add the new field or endpoint, migrate consumers, then remove the old one after usage drops to zero. Consumer-driven contract tests (with a tool such as Pact) let each consumer record the requests and response fields it relies on; the provider's CI replays those expectations and fails before a breaking change ships, without spinning up the whole system. This replaces slow, flaky end-to-end environments as the main safety net. Version events the same way, and keep a written owner for every API so questions have somewhere to go.

09Extraction mechanics: branch by abstraction and the anti-corruption layer

Inside the monolith, branch by abstraction prepares a module for extraction without a long-lived branch. Introduce an interface for the capability, route all callers through it, then add a second implementation that calls the new service, switched by a feature flag per tenant or percentage. Roll forward gradually and keep the in-process implementation as a fallback until the remote one is proven. Where the new service has a cleaner model than the legacy code, put an anti-corruption layer between them: a translator that maps old concepts to new ones so legacy naming and quirks do not leak into the new design. Data moves in phases: the new service first reads a replicated copy, then becomes the writer while the monolith reads from it, and finally the old tables are dropped.

1// Branch by abstraction: callers depend on the interface, not the location
2export interface PricingPort {
3  quote(cartId: string): Promise<Quote>;
4}
5 
6export function pricingFor(tenantId: string, deps: Deps): PricingPort {
7  return deps.flags.isOn("pricing-service", tenantId)
8    ? new RemotePricing(deps.http)      // new service, behind timeouts and retries
9    : new InProcessPricing(deps.db);    // existing module, kept as fallback
10}

10Team topology and the inverse Conway manoeuvre

If systems mirror team communication, you can design the organisation to get the architecture you want: the inverse Conway manoeuvre. Give each stream-aligned team end-to-end ownership of one or a few bounded contexts, including its data, deploys and on-call. A platform team provides paved roads (CI templates, observability, service scaffolding) so every new service does not reinvent them. Watch cognitive load: a team that owns more services than it can reason about will cut corners on all of them. A rough sanity check is the ratio of deployables to engineers; when it goes past one, operations start to dominate feature work. Re-draw boundaries when the team structure changes, because a service owned by three teams becomes a coordination bottleneck, and an orphaned one quietly rots.