Monolith vs Microservices

The monolith-vs-microservices question is one of the most consequential architectural decisions a team can make — and one of the most frequently made wrong. Microservices are often chosen for the wrong reasons (fashion, perceived scalability, "big companies do it") and monoliths are dismissed for the wrong reasons ("not scalable," "old-fashioned"). This page is a direct comparison: what each is genuinely good at, what each makes hard, the modular monolith middle ground most teams should actually build, and the signals that tell you a migration to services is warranted.

Side-by-side comparison

Concern	Monolith	Microservices
Development speed (early)	Fast — one repo, one deploy, no network calls	Slow — infra setup, service contracts, local orchestration
Deployment	One artifact; all-or-nothing	Per-service; independent rollout and rollback
Scaling	Scale everything together	Scale the bottleneck service only
Data consistency	ACID transactions across all data	Eventual consistency; distributed transactions are hard
Debugging / tracing	One log, one stack trace	Distributed traces across services and log streams
Testing	Straightforward integration tests	Must spin up many services; contract tests needed
Operational overhead	One pipeline, one runtime, one monitoring target	N pipelines, N runtimes, N dashboards
Team autonomy	Changes require coordination	Teams own services end-to-end

Monoliths are faster to build and easier to operate; microservices pay off only at organizational or scaling scale

The table is deliberately honest: a monolith is the **better starting point** for almost every project. One codebase means simpler refactoring, a single deploy pipeline, ACID database transactions, trivial cross-module calls, and a debugging experience that fits in one terminal window. These advantages are especially pronounced in the first 1–2 years of a product when the domain is still being discovered and requirements change frequently — the cost of maintaining service boundaries around a poorly-understood domain is very high. Microservices pay off when the **organizational scale** (many independent teams, Conway's Law forcing service boundaries anyway) or **technical scale** (specific hotspot services genuinely need to scale independently) makes the costs worthwhile. "Will need it someday" is not a reason to pay the cost today.

The modular monolith — the best of both

Text

MODULAR MONOLITH: one deployable unit, strict internal boundaries

src/
  modules/
    users/          ← its own service layer, repository, types
      index.ts      ← public API: what other modules MAY call
    orders/
      index.ts      ← public API
    billing/
      index.ts
  shared/           ← genuinely cross-cutting: config, logging, errors

Rules:
  ✅ Module A calls Module B ONLY through B's public index.ts
  ❌ Module A never imports from B's internal files directly
  ❌ Module A never queries B's database tables directly

A modular monolith enforces service-like boundaries inside one process — you get most of the benefits without the distributed-system costs

The **modular monolith** is the architecture most teams should build: one deployable process (simple to run, debug, and deploy) with **strict module boundaries** that mirror eventual service lines. Each module exposes only its public API (`index.ts`) and owns its domain logic and data; no other module reaches inside. The discipline is enforced by convention, ESLint rules, or module bundler configuration. The benefits: you get code organization, clear ownership, and the ability to reason about each module independently — without network calls, distributed transactions, or N CI pipelines. Crucially, a modular monolith is **extractable**: when a module really does need independent scaling or deployment, you already have a clean boundary; the extraction is mostly adding a network layer, not untangling spaghetti. Build this first; extract services when the pain is real.

When microservices are actually warranted

Genuine organizational scale — multiple teams working in the same codebase are slowing each other down with merge conflicts, coordination overhead, and deployment coupling.
Bottleneck isolation — one specific component (search, video processing, recommendations) needs to scale or be replaced independently of the rest.
Technology mismatch — a capability genuinely needs a different runtime (Python for ML, Go for high-throughput, Rust for systems work) that can't share the Node process.
Compliance isolation — a component handling PCI or PHI data must be isolated into its own security boundary.
Team autonomy is a hard requirement — org-level decision that teams must deploy independently; Conway's Law means the architecture follows org structure.

Premature microservices extract the wrong boundaries and create distributed monolith — wait until the boundary is well-understood

The most common microservices failure is **premature extraction**: slicing along domain lines before the domain is understood, then discovering the "services" call each other synchronously for every operation — a distributed monolith with all of the network overhead and none of the independence. Boundaries should emerge from real team ownership, scaling measurements, and proven domain stability — not from an initial architecture diagram. The telling sign of a poorly-chosen boundary is a service that can't do anything useful without synchronously calling another service first. If two services are always deployed together, always tested together, and always call each other — they're one service wearing two coats. Merge them, clarify the domain, and extract again when the boundary is clearer.

The backbone of async microservice communication: [Message Queues](/nodejs/message-queues).