Microservices vs Monolith

Microservices are often treated as a goal rather than a tool. Understanding when the trade-off is worth it separates engineers who ship from engineers who over-engineer.

What is a Monolith?

A monolith is a single deployable unit where all components run together in one process.

┌─────────────────────────────────┐
│         Monolith                │
│  ┌──────────┐  ┌─────────────┐  │
│  │  Orders  │  │  Products   │  │
│  └──────────┘  └─────────────┘  │
│  ┌──────────┐  ┌─────────────┐  │
│  │  Users   │  │  Payments   │  │
│  └──────────┘  └─────────────┘  │
│           One Database          │
└─────────────────────────────────┘

Advantages: Simple to develop, test, and deploy. One codebase, one database, in-process calls.

Problems at scale: Tight coupling, single point of failure, one slow deploy affects everything, can't scale parts independently.

What are Microservices?

Each service is a separately deployable process with its own database.

┌──────────┐  ┌──────────┐  ┌──────────┐
│  Orders  │  │ Products │  │  Users   │
│  Service │  │  Service │  │  Service │
│  DB      │  │  DB      │  │  DB      │
└──────────┘  └──────────┘  └──────────┘
      │              │             │
      └──────────────┴─────────────┘
                API Gateway

Advantages: Independent scaling, independent deployment, polyglot tech stack.

Problems: Network latency, distributed transactions, operational complexity, service discovery.

What Microservices Actually Solve

1. Independent scaling — your orders service gets 100x traffic in Black Friday. Scale it without scaling payments.
2. Team autonomy — the payments team deploys without coordinating with the catalog team.
3. Fault isolation — a crash in the recommendations service doesn't take down checkout.
4. Technology choice — the ML service uses Python; the API uses .NET.

What They Actually Introduce

Monolith call:        orderService.CreateOrder(request)   — 1 μs
Microservices call:   HTTP POST /orders                   — 10-50 ms
                      + serialization
                      + network
                      + service discovery
                      + potential retry on failure

Every inter-service call is now:

• Slower — network vs in-process
• Fallible — network can fail; you need retries and circuit breakers
• Eventual — distributed transactions don't work; you get eventual consistency

The Strangler Fig Pattern — Migrate Gradually

Don't rewrite everything. Extract services one at a time.

1. Start with a monolith
2. Identify a bounded context that needs to scale or change frequently
3. Extract it as a service behind an API
4. Route traffic to the new service
5. Remove the old code from the monolith
6. Repeat

A Better Starting Point: Modular Monolith

A modular monolith has clean internal boundaries without the operational complexity of distributed systems.

┌─────────────────────────────────┐
│       Modular Monolith          │
│  ┌──────────┐  ┌─────────────┐  │
│  │  Orders  │  │  Products   │  │ ← Modules with internal APIs
│  │  Module  │  │  Module     │  │   (not microservices — no network)
│  └──────────┘  └─────────────┘  │
│  Shared DB (with schema separation) │
└─────────────────────────────────┘

You can extract microservices later if you actually need to.

Decision Framework

Start with a monolith when:
  ✓ Team < 10 engineers
  ✓ Domain not fully understood yet
  ✓ Moving fast is the priority
  ✓ Operational simplicity matters

Consider microservices when:
  ✓ Teams > 30 engineers working on different domains
  ✓ Parts of the system have wildly different scaling needs
  ✓ You have a mature DevOps culture (CI/CD, observability, on-call)
  ✓ One service's tech stack can't serve another's needs

Key Takeaways

1. Start with a monolith — premature decomposition is one of the most expensive mistakes in software
2. Microservices solve team scaling and independent deployment — not technical performance (a well-tuned monolith can serve millions of users)
3. Distributed systems are hard — every network call can fail; you need retries, circuit breakers, and eventual consistency patterns
4. A modular monolith gives you clean boundaries without the operational overhead of microservices
5. Extract services when the pain of the monolith exceeds the pain of distributed systems — not before