Chapter 9 — Microservices vs Monolith

The why

Microservices are not the goal. Shipping working software that your team can maintain is the goal. Sometimes that's a monolith.

Core concepts

The modular monolith: Best of both worlds

A modular monolith is a single deployable application with strong internal boundaries. Think of it as a well-organized monolith that can be split later:

src/
├── modules/
│   ├── users/
│   │   ├── users.controller.ts
│   │   ├── users.service.ts
│   │   ├── users.repository.ts
│   │   └── index.ts          // Public API of the module
│   ├── orders/
│   │   ├── orders.controller.ts
│   │   ├── orders.service.ts
│   │   ├── orders.repository.ts
│   │   └── index.ts
│   ├── payments/
│   │   └── ...
│   └── notifications/
│       └── ...
├── shared/
│   ├── database.ts
│   ├── logger.ts
│   └── errors.ts
└── app.ts                    // Wires modules together

The key rule: modules communicate only through their public API (index.ts). The orders module calls users.findById() — never SELECT * FROM users directly. This boundary is enforced by convention (and ideally by tooling like ESLint import rules or Nx module boundaries).

// modules/users/index.ts — the ONLY public interface
export { UsersService } from './users.service';
export type { User, CreateUserInput } from './users.types';
 
// modules/orders/orders.service.ts — consumes the public interface
import { UsersService } from '../users';

If every module respects these boundaries, extracting a module into a separate service later becomes a deployment change, not a rewrite.

When to extract a service: The bounded context rule

Domain-Driven Design's "bounded context" concept is the best heuristic for service boundaries. A bounded context is a part of your system with its own ubiquitous language — its own words, rules, and constraints.

Signals that a module should become its own service:

1. Different deployment cadence. The payments module changes weekly (new payment methods, compliance updates). The users module changes quarterly. Keeping them in the same deployable means every payment change risks breaking user functionality.

2. Different scaling requirements. The search module handles 10,000 req/s and needs 12 instances. The admin module handles 100 req/s and needs 1 instance. In a monolith, you scale everything together — wasting resources.

3. Different team ownership. Team A owns orders. Team B owns inventory. In a monolith, Team A's deploy can break Team B's code. Separate services let teams deploy independently.

4. Different data storage requirements. analytics needs a columnar database (ClickHouse). users needs a relational database (PostgreSQL). A monolith generally uses one primary database.

5. Fault isolation. The recommendation engine is experimental and crashes occasionally. In a monolith, its crash takes down the entire app. As a separate service, it degrades gracefully (recommendations disappear, but checkout still works).

Service communication patterns

Once you have separate services, they need to talk:

Synchronous (HTTP/gRPC):

// Order service calls Payment service to charge a card
const response = await fetch('https://payments.internal/api/charges', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ amount: 2999

Pro: Simple, familiar, request-response model. Con: Tight coupling — if the payment service is down, the order fails. This is where circuit breakers become essential:

import { CircuitBreaker } from 'opossum';
 
const breaker = new CircuitBreaker(async (chargeData) => {
  const res = await fetch('https://payments.internal/api/charges', {
    method: 'POST',
    headers

When the circuit opens, the order service can accept the order and queue payment for later, rather than rejecting the customer entirely.

Asynchronous (message broker): Loose coupling, natural queuing, retry logic. Con: Eventual consistency, harder to debug, requires idempotent consumers.

The Strangler Fig Pattern: Migration without a rewrite

Named after the fig tree that grows around a host tree and gradually replaces it. Applied to software: build new functionality as microservices, gradually replacing monolith functionality piece by piece. A proxy (nginx, API gateway) incrementally redirects traffic. The monolith shrinks until it can be retired. At no point is the entire system rewritten.

Data ownership: One service, one database

Each microservice owns its data. No other service reads or writes that data directly. Shared database = shared schema = coupling at the most fundamental level. You can't change the Users schema without coordinating with the Orders team. The API is the contract; the database schema is an implementation detail.

The Double-Write Problem

When an operation spans two services with separate databases, you need consistency:

Solutions:

1. Saga pattern (eventual consistency): Each step emits an event. If a later step fails, previous steps execute compensating transactions.

2. Transactional outbox: Write the event to the SAME database transaction as the business data. A separate process publishes events reliably.

3. Two-Phase Commit (2PC): Rarely used in microservices — blocks both databases, doesn't scale, fails if coordinator crashes.

Real-world example: How Amazon migrated from monolith to services

Amazon's transformation from monolith to microservices is the canonical case study. In the early 2000s, Amazon.com was a massive monolithic C++ application (Obidos). Every deploy took weeks. A change to the recommendation algorithm could break checkout.

In 2002, Jeff Bezos issued what became known as the "API Mandate" — an internal memo requiring all teams to:

1. Expose their data and functionality through service interfaces.
2. Communicate exclusively through those interfaces.
3. No direct database access across teams. No shared memory. No backdoors.
4. Any deviation required VP approval.

This mandate forced Amazon to decompose their monolith into hundreds of services. Each team owned their service end-to-end (build, deploy, operate). The "two-pizza team" rule (teams small enough to feed with two pizzas) emerged from this decomposition.

The result: Amazon went from deploying once every few weeks to deploying every 11.7 seconds (by 2015). Independent services meant independent deploy schedules. The recommendation team could update their algorithm without coordinating with the checkout team.

But the migration took YEARS, not months. Amazon didn't rewrite the monolith — they used the Strangler Fig pattern, extracting functionality service by service. The original Obidos monolith still runs some legacy functionality to this day.

The lesson: Amazon's success came from organizational change (the API mandate, two-pizza teams) as much as technical change. Conway's Law states that organizations design systems that mirror their communication structure. Amazon restructured their teams first; the microservices architecture followed naturally.

Common mistakes

Production notes

• Distributed tracing is non-negotiable. When a request touches 5 services, you need to see the entire journey. Use OpenTelemetry with Jaeger or Zipkin. Every service propagates traceparent headers.
• Centralized logging. Don't SSH into 20 servers to debug an error. Ship all logs to a central system (ELK stack, Datadog, Grafana Loki). Include traceId in every log line.
• Health checks and readiness probes. Each service needs /health (is the process alive?) and /ready (can it serve traffic? DB connected? Dependencies available?). Kubernetes uses these for auto-restart and traffic routing.
• Contract testing over end-to-end testing. Testing 10 services together is flaky and slow. Use contract tests (Pact) to verify that Service A's expectations match Service B's actual responses. Test each service in isolation.
• Graceful degradation. If the recommendation service is down, show a static "Popular items" section — don't fail the entire page. Every dependency should have a fallback.

Performance notes

• Network latency accumulates. A monolith function call takes microseconds. A service-to-service HTTP call takes 1-50ms. A chain of 5 services = up to 250ms added latency. Batch requests or use async messaging for non-critical paths.
• gRPC over REST for internal services. gRPC uses Protocol Buffers (binary, smaller payload) and HTTP/2 (multiplexing, streaming). For service-to-service communication, gRPC is typically 7-10x faster than REST/JSON.
• Connection pooling between services. Don't create a new HTTP connection per request. Use keep-alive connections. For gRPC, the channel is long-lived by default. For REST, configure your HTTP client with keepAlive: true and maxSockets.
• Cache service responses when possible. If Service A frequently asks Service B for user profiles, cache the response for 60 seconds. Stale data is better than no data. Use Redis or in-memory cache with TTL.

Security notes

• Service-to-service authentication. Don't trust internal traffic by default. Use mutual TLS (mTLS) or API keys between services. A compromised service shouldn't have unrestricted access to every other service.
• Principle of least privilege for service accounts. Each service gets database credentials scoped to exactly the tables it needs. The orders service can't read the users table. Use PostgreSQL row-level security or separate database users.
• Validate inputs at every service boundary. Even if Service A validated the data, Service B should validate it again. Defense in depth. A bug in Service A's validation shouldn't corrupt Service B's data.
• Audit service-to-service calls. Log which service called which endpoint, when, and with what result. This is essential for breach investigation and compliance (SOC 2, GDPR).

Exercises

Beginner

1. Refactor into a modular monolith: Take a monolithic Express app where controllers directly query the database. Refactor into modules (users, posts, comments) with clear public APIs. Enforce module boundaries with ESLint import/no-restricted-paths.

2. Implement a circuit breaker: Add the opossum library to an endpoint that calls an external API. Configure a circuit breaker with timeout, error threshold, and fallback. Test by killing the external API and verifying your endpoint returns the fallback response.

Intermediate

3. Extract a service from the monolith: Choose one module from your modular monolith (e.g., users). Extract it into a separate Express service with its own database. Update the monolith to call the new service via HTTP. Add a circuit breaker to the monolith's calls.

4. Implement the outbox pattern: In the extracted users service, write user-creation events to an outbox table in the same transaction. Build a worker that polls the outbox and publishes events to RabbitMQ. Verify eventual delivery even when RabbitMQ is temporarily down.

Advanced

5. Implement a saga for a distributed transaction: Build an order-placement saga spanning three services (orders, inventory, payments). Each step emits an event; failures trigger compensating transactions. Test the scenario where step 3 fails and verify steps 1 and 2 are compensated.

6. Strangler Fig migration: Set up an nginx reverse proxy in front of your monolith. Extract one endpoint to a new service. Configure nginx to route that endpoint's traffic to the new service. Monitor both services. Gradually extract more endpoints until the monolith handles zero traffic.

Interview questions

Beginner

1. Q: What's the difference between a monolith and microservices? A: A monolith is a single deployable application where all functionality runs in one process. Microservices split functionality across multiple independently deployable services, each owning a specific business capability. Monoliths are simpler to develop and debug; microservices enable independent scaling, deployment, and team ownership.

2. Q: What is a modular monolith? A: A modular monolith is a single deployable application with strong internal boundaries between modules. Modules communicate through defined interfaces (not direct database access) and could be extracted into separate services later. It gives you the development simplicity of a monolith with the organizational clarity of microservices.

3. Q: What is Conway's Law? A: "Organizations design systems that mirror their communication structure." If you have 4 teams that don't communicate well, you'll end up with 4 poorly integrated services. The architecture reflects the org chart. To change the architecture, you often need to change the org structure first.

Senior

4. Q: Your company has a monolith that takes 45 minutes to deploy and causes weekly production incidents because one team's change breaks another team's functionality. 200 developers work on it. How do you approach decomposition without a 2-year rewrite? A: Start with the Strangler Fig pattern. Identify the module causing the most deployment friction (most frequent changes, most incidents). Extract it first — it gives the biggest ROI. Put a proxy in front. Route its traffic to the new service. Repeat. Key success factors: (1) Get executive buy-in for a multi-year investment. (2) Don't extract everything — some modules will never change enough to justify extraction. (3) Invest in observability first (distributed tracing, centralized logging). (4) Set a clear metric for success (deploy time < 10 min, incident rate -50%). (5) Accept that some functionality stays in the monolith forever — a "monolith plus services" hybrid is a valid end state.

5. Q: How do you handle a business transaction that spans 3 microservices without distributed transactions? A: Use the Saga pattern. Each service performs its local transaction and publishes an event. If a downstream step fails, the preceding services execute compensating transactions (semantic undo). For example: Order Service → (OrderCreated event) → Inventory Service reserves stock → (InventoryReserved) → Payment Service charges → (PaymentFailed) → Inventory Service releases stock (compensate) → Order Service cancels order (compensate). The system is eventually consistent. For critical flows, use reservation patterns: reserve stock for 15 minutes, release if payment doesn't complete.

6. Q: You're evaluating whether to extract a service from the monolith. What metrics do you look at, and what's your decision framework? A: Metrics: (1) Deployment frequency — if this module deploys 5× more often than the rest, it's a candidate. (2) Incident correlation — if this module's bugs cause incidents in other modules, isolation helps. (3) Resource usage — if this module needs different scaling (CPU/memory/I/O profile), separate deployment saves cost. (4) Team ownership — if 2+ teams modify this module and constantly conflict, separation reduces coordination overhead. Extract only when at least 2 of these metrics are clearly painful AND the team has operational maturity (CI/CD, monitoring, on-call rotation).

Summary

Microservices are an organizational pattern, not a technical silver bullet. They solve problems of team scale, deployment independence, and fault isolation — at the cost of network complexity, eventual consistency, and operational overhead. The modular monolith is the underrated middle ground: strong internal boundaries, single deployment, extractable later. When you do extract, use the Strangler Fig pattern to migrate incrementally without a rewrite. The golden rule: one service owns its data. If you're sharing databases, you don't have microservices — you have a distributed monolith, which is the worst of both worlds. Start monolith, go modular, extract only when the pain of staying together exceeds the pain of splitting apart.

Quick recall

• Modular monolith: one deployable, strong module boundaries, communication via public APIs.
• Bounded context: DDD concept — a boundary where a specific domain model applies. The best heuristic for service boundaries.
• Strangler Fig pattern: incrementally replace monolith functionality with new services behind a proxy.
• Distributed monolith: services that all depend on each other — monolith complexity with network latency.
• Double-write problem: when one operation spans two databases. Solved by Saga (eventual consistency) or outbox (reliable event publication).
• Circuit breaker: prevents cascading failures when a downstream service is unhealthy.
• One service, one database. Services communicate via API, never direct DB access.
• Amazon's API Mandate (2002) forced service interfaces and two-pizza teams — the organizational foundation for their microservices.

Quiz

1. What pattern incrementally replaces monolith functionality with new services behind a proxy? A: Strangler Fig pattern

2. What's the term for microservices that all depend on each other, combining the worst of both architectures? A: Distributed monolith

3. What DDD concept is the best heuristic for microservice boundaries? A: Bounded context

4. True or false: Each microservice should have its own database. A: True — shared databases couple services at the schema level.

5. What pattern ensures reliable event publication when a database write and event publish must be atomic? A: Transactional outbox pattern

6. What AWS team structure rule emerged from Amazon's microservices migration? A: Two-pizza teams (teams small enough to feed with two pizzas, ~6-8 people)

7. Which pattern coordinates a distributed transaction across services using compensating transactions? A: Saga pattern