Chapter 15 — Monolith vs Microservices

Shreyesh kolhe
July 10, 2026

Chapter 15 — Monolith vs Microservices

Hey everyone! Welcome back to Namaste System Design! 🙏

This is the architecture debate everyone has an opinion on — and most opinions are wrong. Junior engineers think "microservices = modern = better." Senior engineers know it's a trade-off, and that starting with microservices is often a costly mistake. Let's give you the mature, interview-winning take.

What we will cover:

  • What a monolith is (one big box)
  • What microservices are (many small boxes)
  • The restaurant-kitchen analogy
  • Pros and cons of each — honestly
  • The hidden costs of microservices
  • Which to start with (the senior answer)
  • Interview Questions

1. The Monolith — One Big Box

A monolith is a single application where all features live in one codebase and deploy together.

   ┌─────────────────────────────────┐
   │        THE MONOLITH             │
   │  ┌────────┐ ┌────────┐          │
   │  │ Users  │ │ Orders │          │   ONE codebase
   │  ├────────┤ ├────────┤          │   ONE deploy
   │  │Payments│ │ Search │          │   ONE database (usually)
   │  └────────┘ └────────┘          │
   └─────────────────────────────────┘
        deploys as a single unit

Every startup should basically start here. It's simple, fast to build, and easy to reason about.

2. Microservices — Many Small Boxes

Microservices split the app into small, independent services, each owning one business capability, its own database, and its own deployment.

   ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐
   │ Users  │  │ Orders │  │Payments│  │ Search │
   │ service│  │ service│  │ service│  │ service│
   │  +DB   │  │  +DB   │  │  +DB   │  │  +DB   │
   └───┬────┘  └───┬────┘  └───┬────┘  └───┬────┘
       └───────────┴─── talk via APIs / queues ───┘

   Each: own codebase, own DB, own deploy, own team.

3. The Restaurant Analogy

   MONOLITH  = one chef 👨‍🍳 who does EVERYTHING — starters,
               mains, desserts, dishes. Simple when small.
               But if that chef is sick, the whole kitchen stops.
               And you can't "hire a dessert specialist" easily.

   MICROSERVICES = separate stations: a starter chef, a grill
               chef, a pastry chef 👨‍🍳👩‍🍳🧑‍🍳. Each is expert &
               independent. Grill station busy? Add another grill
               cook without touching pastry. But now they must
               COORDINATE — and coordination is hard.

4. Honest Pros & Cons

MonolithMicroservices
Simplicity✅ Simple to build, test, deploy❌ Complex — many moving parts
Speed to start✅ Fast (one codebase)❌ Slow (infra, networking, DevOps)
Scaling❌ Scale the WHOLE app even if only search is hot✅ Scale just the busy service
Deployment❌ One bug can block the whole release✅ Deploy services independently
Fault isolation❌ A crash can take everything down✅ One service fails, others survive
Team autonomy❌ Everyone in one codebase (merge pain)✅ Teams own services independently
Debugging✅ One place, easy stack traces❌ Hard — trace across many services (Ch 16)
Data consistency✅ Easy (one DB, transactions)❌ Hard (distributed data, no easy transactions)

5. The Hidden Costs of Microservices

The brochure sells the benefits. Here's what it doesn't tell you:

❌ NETWORK is now everywhere → calls that were function calls
   are now network calls (slow, can fail, need retries).

❌ DISTRIBUTED transactions → "deduct payment AND create order"
   spans two services → no simple transaction (need Saga pattern).

❌ DEBUGGING is painful → one user request touches 10 services.
   Where did it break? (This is why we need distributed tracing.)

❌ OPERATIONAL overhead → dozens of deployments, service
   discovery, monitoring, a whole DevOps/Kubernetes practice.

❌ EVENTUAL CONSISTENCY → separate DBs drift; you inherit all
   the CAP/consistency problems from Chapters 09 & 14.

The famous warning: "Microservices solve an organizational problem (many teams stepping on each other), not a technical one. If you have one small team, they mostly add pain."

6. Which Should You Start With?

┌─────────────────────────────────────────────────────────────┐
│   THE SENIOR ANSWER: "Start with a monolith."               │
│                                                             │
│   → Build a well-structured ("modular") monolith first.     │
│   → Split OUT microservices later, ONLY when a real pain    │
│     appears: a team is too big, or one part needs to scale  │
│     very differently.                                       │
│                                                             │
│   This is the "MonolithFirst" strategy. Amazon, Netflix,    │
│   Shopify all STARTED as monoliths and split later.         │
└─────────────────────────────────────────────────────────────┘

When microservices genuinely make sense: large org with many independent teams; parts of the system with wildly different scaling needs; the need to deploy pieces independently many times a day.

Interview Questions — Quick Fire!

Q: What's the difference between a monolith and microservices?

"A monolith is a single application where all features share one codebase, one deployment, and usually one database. Microservices split the application into small, independent services, each owning a business capability with its own database and deployment, communicating over APIs or message queues. Monoliths are simpler; microservices offer independent scaling and deployment at the cost of significant complexity."

Q: What are the main benefits of microservices?

"Independent scaling — you scale only the busy service; independent deployment — teams ship without coordinating one big release; fault isolation — one service failing doesn't necessarily bring down the rest; and team autonomy — separate teams own separate services and move faster. They shine when you have many teams and components with very different scaling needs."

Q: What are the downsides of microservices?

"They add a lot of complexity: network calls replace function calls and can fail; transactions across services become hard, needing patterns like Saga; debugging a request that spans many services requires distributed tracing; and there's heavy operational overhead — service discovery, many deployments, monitoring, orchestration. You also inherit distributed data consistency problems."

Q: Should a new startup start with microservices?

"Generally no. The mature advice is to start with a well-structured monolith, which is faster to build and easier to operate, and only extract microservices later when a concrete pain emerges — like a team growing too large or a component needing very different scaling. Many big companies started as monoliths and split gradually. Microservices mostly solve an organizational scaling problem, not a technical one."

Key Points to Remember

ConceptKey Takeaway
MonolithOne codebase/deploy/DB. Simple, fast to start, easy to debug. Scales as a whole.
MicroservicesMany independent services. Independent scale/deploy + fault isolation, but complex.
Hidden costsNetwork everywhere, distributed transactions, hard debugging, ops overhead.
Start withA modular monolith. Split out services only when a real pain appears.
Real reasonMicroservices solve an organizational problem (many teams), not a technical one.

What's Next?

Once you have many services and machines, a scary question appears: "It's broken — but WHERE?" Chapter 16 covers observability — logs, metrics, and traces — the tools that let you see inside a running system.

Keep designing, keep scaling! See you in the next one!