Monolith vs Microservices: An Honest Comparison

The monolith

A monolith is one application. It usually has one codebase, it is deployed as one unit (all parts released together), and it typically uses one database.

Strengths:

• ✅ Simple to build, run and debug. There is one process (one running program), one log stream and one stack trace (the list of function calls that led to an error). The "go to definition" feature of your editor works across all the code.
• ✅ Fast function calls instead of network calls. There is no serialisation (turning data into bytes to send), no network failure and no timeout between modules.
• ✅ Real ACID transactions across features (post 21). A transaction is a group of database changes that either all succeed or all fail. ACID is the set of guarantees that make this safe.
• ✅ Easy refactoring (cleaning up the structure of code), because moving code between modules is a normal code change.
• ✅ Simple deployment and testing: one build pipeline and one output file (artefact) to release.
• ✅ Scales further than people think: run many copies behind a load balancer (a server that spreads requests across copies, post 7).

Weaknesses (mostly as it grows):

• ❌ Team coupling: many teams in one codebase get in each other's way, and releases need planning between teams.
• ❌ Slow builds and deploys as the code grows.
• ❌ Blast radius: this means how much a failure can damage. A memory leak (a bug that slowly uses up memory) in one feature can crash everything (post 40).
• ❌ You scale everything together, even if only search needs more CPU. (To scale means to add more capacity.)
• ❌ One technology stack for everything.
• ❌ Boundaries wear away: without discipline, modules reach into each other's inner parts. The code becomes a "big ball of mud", which means a tangled mess.

Microservices

Microservices split the system into small services that can be deployed on their own. Each service owns one business capability (one job, like payments) and its own data. The services talk to each other over the network (REST, gRPC or events). REST and gRPC are two ways to call another service. An event is a message that says "something happened".

Key principles:

• Organised around business capabilities (orders, payments, catalogue), not around technical layers (like a "database service" or a "UI service").
• Independently deployable: a team ships its service without coordinating with others.
• Database per service: no other service reads its tables directly. They must use its API or events.
• Owned by one team ("you build it, you run it").
• Designed for failure: use timeouts, retries, circuit breakers (stop calling a service that keeps failing) and fallbacks (a backup answer) (Part 7).

Strengths:

• ✅ Team independence: teams deploy on their own schedule, many times a day.
• ✅ Independent scaling: run search on 50 instances (copies) and user profiles on 3.
• ✅ Fault isolation: a failure stays in one place. If recommendations crash, checkout can keep working (with good design, posts 42 and 44).
• ✅ Technology freedom: use the right language or database per service (with limits).
• ✅ Smaller codebases that are easier to understand individually.

Costs (often underestimated):

• ❌ Network calls everywhere: latency, partial failures, timeouts and retries. The "fallacies of distributed computing" (well-known wrong beliefs about networks) apply. The network is not reliable, and latency (the delay of a call) is not zero.
• ❌ Distributed data: there are no transactions across services. So you need sagas (a chain of local steps, with undo steps if one fails), eventual consistency (data becomes the same everywhere after a short delay) and copies of data (posts 23, 28 and 39).
• ❌ Operational overhead: you must deploy, monitor, secure, patch and pay for dozens or hundreds of services. You need strong CI/CD (automatic build and release), containers, orchestration (a system that runs and manages containers), observability and on-call (posts 46–48 and 55–58).
• ❌ Harder debugging: one user request crosses 10 services, so you need distributed tracing (post 46).
• ❌ Harder testing: you need integration tests and contract tests across services. A contract test checks that two services still agree on the shape of their messages.
• ❌ API versioning between services, so that old callers keep working when an API changes (post 34).
• ❌ The "distributed monolith" trap: the services are split, but they are still tightly coupled (they depend closely on each other). They must be deployed together, share a database, or call each other in long chains where each one waits for the next. You get all the costs and none of the benefits.

The middle path: the modular monolith

A modular monolith is one deployable application that is split inside into modules (parts) with strong boundaries:

• Each module has a clear public interface. Others can't reach into its internals, and this is enforced by tooling, package rules or architecture tests.
• Each module owns its tables. Other modules don't query them directly.
• You get most of the simplicity of a monolith and much of the organisation of microservices.
• If a module later needs to become a service (for scaling or team reasons), the boundary is already clean, so extracting it is much easier.

For many companies, a modular monolith is the best long-term architecture, not just a stepping stone.

How to find service (or module) boundaries

• Domain-Driven Design (DDD) is a way of designing software around the business. Split by bounded contexts, which are areas of the business with their own language and rules. "Product" means different things to the catalogue team (description, images), the inventory team (stock levels) and the pricing team (price rules).
• High cohesion, low coupling: cohesion means the parts of a module belong together. Coupling means how much modules depend on each other. Things that change together belong together. If two services always change together, they should probably be one.
• Conway's Law: "organisations design systems that copy their own communication structure." Your architecture will end up matching your team structure, so plan both together. Doing this on purpose is sometimes called the "inverse Conway manoeuvre".
• Data ownership: who is the single source of truth for each piece of data?

Migrating: the strangler fig pattern

Do not rewrite a monolith from scratch in one go. This "big-bang rewrite" fails very often. Instead, replace the pieces step by step. This is like a strangler fig, a vine that slowly grows around a tree until it takes its place:

1. Put a proxy or gateway in front of the monolith (post 13). A proxy is a server that receives requests and passes them on.
2. Build one new service (say, payments) and route its requests to the new service.
3. Move data carefully (post 29). Use dual writes (write to both old and new database), CDC (change data capture, which copies each database change to another system) and checks that both sides match.
4. Repeat, one capability at a time, until the monolith is small, or gone.

Signals for each choice

Stay with (or start with) a monolith / modular monolith when:

• the team is small (one or a few teams),
• the business area (domain) is still changing fast and the boundaries are not clear yet,
• you do not yet have strong CI/CD, containers, monitoring and on-call habits,
• speed of product iteration matters more than independent scaling.

Consider microservices when:

• many teams are blocked by each other in one codebase,
• deployments have become slow, risky and heavily coordinated,
• parts of the system have very different scaling, reliability or security needs (like payments vs a marketing blog),
• boundaries are well understood, and
• you have the platform maturity to run many services: automation, observability, service discovery (how services find each other, post 54) and security.

Martin Fowler's well-known advice is "Monolith first." Almost every successful microservices story he saw began with a monolith that grew too big. Systems built as microservices from the start often ran into trouble.