Monolith vs Microservices

1What a Monolith Is

A monolith is a system deployed as a single unit: one codebase, one build artifact, one running process (or a set of identical replicas of that same process behind a load balancer). OrderService, InventoryService, and PaymentService might exist as separate classes or modules internally, but they all run inside the same process and talk to each other via in-process function calls.

┌─────────────────────────────────────────┐
│              order-api (1 process)        │
│  ┌───────────┐ ┌───────────┐ ┌─────────┐ │
│  │  Orders   │ │ Inventory │ │ Payments│ │
│  │  module   │ │  module   │ │ module  │ │
│  └─────┬─────┘ └─────┬─────┘ └────┬────┘ │
│        └──────function calls──────┘       │
└─────────────────────┬─────────────────────┘
                       │
                 ┌─────▼─────┐
                 │  1 database │
                 └───────────┘

A function call between Orders and Inventory here is a normal call: same memory space, same stack, microsecond latency, and if it throws, the caller catches it directly.

2What Microservices Are

Microservices split the same functionality into independently deployable services, each with its own process, its own deployment lifecycle, and — critically — usually its own database. Services talk to each other over the network: HTTP/REST, gRPC, or asynchronous messaging (queues, event streams).

┌───────────┐        ┌───────────┐        ┌───────────┐
│  orders   │──HTTP──▶│ inventory │        │ payments  │
│  service  │        │  service  │        │  service  │
└─────┬─────┘        └─────┬─────┘        └─────┬─────┘
      │                    │                     │
 ┌────▼────┐         ┌────▼────┐          ┌────▼────┐
 │ orders   │         │inventory│          │payments  │
 │   DB     │         │   DB    │          │   DB     │
 └─────────┘         └─────────┘          └─────────┘

The same Orders → Inventory interaction that was a function call in the monolith is now a network call: serialize a request, send it over a socket, wait, deserialize a response — and it can fail in ways a function call never can (see Under the Hood).

3Side-by-Side Comparison

4Why Teams Reach for Microservices

• Independent scaling. If Inventory gets 100x the traffic of Payments, scale only Inventory's replicas instead of the whole monolith.
• Independent deployment. Team A ships ten times a day without coordinating a release train with Team B.
• Fault isolation. A memory leak or crash loop in Recommendations shouldn't be able to take Checkout down with it, if the boundary is real.
• Technology heterogeneity. One service can be Python for ML, another Go for a hot path, another Node for I/O-bound work.
• Organizational scaling. Conway's Law in action: many small teams work best when the system is decomposed to match team boundaries, not one giant shared codebase everyone steps on.

5Why Microservices Are Not Free

• The network is unreliable. Every inter-service call is now subject to latency, timeouts, partial failure, and retries — none of which existed for a function call (see Under the Hood).
• Data consistency gets hard. No more BEGIN; UPDATE orders; UPDATE inventory; COMMIT; — see the Distributed Transactions and CAP Theorem topics.
• Operational overhead multiplies. You now need service discovery, distributed tracing, centralized logging, per-service on-call, contract testing, and a deployment pipeline per service.
• Debugging a single request means tracing it across N services, N sets of logs, and N potential points of failure.
• Premature decomposition is a common and expensive mistake — splitting a system before its module boundaries are well understood usually produces a distributed monolith: all the network overhead of microservices with none of the independence, because services still have to change together.

6Decision Guide

A common, pragmatic path: start with a modular monolith (next topic) — a single deployable with strict internal module boundaries — and extract a module into its own service only once it has a real, proven reason (a scaling mismatch, an ownership boundary that keeps causing conflict, a genuine need for independent deployment).

function createOrder(cart) {
  const reserved = inventory.reserve(cart.items); // in-process call
  if (!reserved) throw new Error("out of stock");
  return db.insertOrder(cart);
}

async function createOrder(cart) {
  const res = await fetch("http://inventory-service/reserve", {
    method: "POST",
    body: JSON.stringify({ items: cart.items }),
    signal: AbortSignal.timeout(2000),
  });
  if (!res.ok) throw new Error("reservation failed");
  return db.insertOrder(cart);
}

⚠️ Common Pitfalls

1. Decomposing into services before the domain boundaries are understood — produces a distributed monolith: services that must deploy together anyway, but now pay full network overhead for every interaction.
2. Treating a network call like a function call — no timeout, no retry policy, no handling for the "unknown" outcome described above.
3. Splitting services along technical layers (e.g. "database service," "validation service") instead of business capabilities — causes every real feature to require changes across multiple services.
4. Sharing a database across "independent" services — silently recreates a monolith's coupling while paying for microservices' operational cost, with none of the isolation.
5. Choosing microservices for scale before scale is actually a measured problem — most systems never hit the point where a monolith can't be scaled with more replicas behind a load balancer.

📋 Quick Reference

Monolith:      1 process, in-process calls, 1 DB, low ops overhead, hard to scale/deploy parts independently
Microservices: N processes, network calls, N DBs, high ops overhead, easy to scale/deploy parts independently
Function call outcomes:  success | throw                       (always resolved before caller continues)
Network call outcomes:   success | failure | UNKNOWN (timeout) (caller must design for "did it happen?")
Default advice: start monolith (or modular monolith) → extract a service only with a proven, specific reason

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: dist_monolith_vs_microservices_theory.md · generated by tools/build_lessons.py