---
title: "Monolith vs. Microservices: The 'Mansion vs. Village' Mental Model"
description: "Is Microservices mostly hype? A mastery guide to the 'Distributed Monolith', Latency taxes, and knowing when to split."
pubDate: "2023-05-21"
lang: "en"
slug: "monolith-vs-microservices"
url: "https://hoangyell.com/monolith-vs-microservices/"
author: "HoangYell"
translation_vi: "https://hoangyell.com/vi/monolith-vs-microservices/"
categories: ["System Design"]
tags: ["system-design", "architecture", "microservices"]
heroImage: "https://raw.githubusercontent.com/HoangGeek/store/main/webp/photo-1577495508326-19a1b3cf65b7.webp"
---

"We are rewriting our Monolith into Microservices."

This sentence has destroyed more startups than bad product-market fit.

Engineers love Microservices because it looks like Netflix.
Business owners hate Microservices because features take 3x longer to ship.

This is the **Mastery Guide** to Architecture. We'll find out why a Monolith is usually better, and the *exact moment* you should actually switch.

***

## Part 1: Foundations (The Mental Model)

### The Monolith = The Mansion
Imagine a huge **Mansion** where everyone lives together (Auth, Payments, Users, Orders).
*   **Communication**: Instant. If the Cook needs the Butler, he just shouts. (Function calls in memory: Nanoseconds).
*   **Database**: One giant pantry. Everyone shares the ingredients.
*   **Deployment**: You fix the roof? You have to evacuate the whole house for a day. (Redeploy the whole app).
*   **Risk**: If the kitchen catches fire, the whole house burns down.

### Microservices = The Village
Imagine a **Village** of small, separate houses.
*   **Communication**: Slow. The Cook has to walk down the street to ask the Butler for salt. (Network calls: Milliseconds).
*   **Database**: Every house has its own small fridge. No sharing allowed.
*   **Deployment**: You can fix the Butler's roof while the Cook keeps cooking. Independent scaling.
*   **Risk**: If the kitchen burns down, the rest of the village is safe... but now nobody has dinner.

```markdy
scene width=1150 height=650
theme: light=doodle dark=nebula
layout auto

group monolith: InProcessAuth InProcessOrders InProcessPayments SharedDB
group village: AuthSvc OrderSvc PaymentSvc AuthDB OrderDB PaymentDB

service InProcessAuth "Auth Module"
service InProcessOrders "Orders Module"
service InProcessPayments "Payments Module"
database SharedDB "Shared DB (Single Pantry)"

service AuthSvc "Auth Microservice"
service OrderSvc "Orders Microservice"
service PaymentSvc "Payments Microservice"
database AuthDB "Auth DB"
database OrderDB "Orders DB"
database PaymentDB "Payments DB"

beat compare_monolith "1. The Monolith Mansion (Nanosecond In-Memory)" {
  show monolith stagger=40ms
  frame monolith zoom=1.12
  InProcessOrders -> InProcessAuth "in-memory call (0.001ms)"
  InProcessOrders -> InProcessPayments "in-memory call"
  InProcessOrders -> SharedDB "direct query"
  glow monolith color=#22c55e

}
beat compare_village "2. The Microservices Village (Network Latency Tax)" {
  show village stagger=40ms
  frame village zoom=1.12
  OrderSvc -> AuthSvc "HTTP / gRPC (15ms)"
  OrderSvc -> PaymentSvc "HTTP / gRPC (20ms)"
  OrderSvc -> OrderDB "isolated query"
  PaymentSvc -> PaymentDB "isolated query"
  glow village color=#38bdf8
}

player:
    playback:
      loop true
    controls:
      speed true
      speeds "0.25"
      fullscreen true
      gif true
      theme true
    interaction:
      zoom true
      pan true
      click_to_play true
      double_click_to_reset true
      keyboard false
    chrome:
      badge true
      progress none
```

***

## Part 2: The Investigation (The Hidden Costs)

Switching to Microservices is not free. You are trading **Code Complexity** for **Operational Complexity**.

### 1. The Latency Tax
In a Monolith, `UserService.getUser()` takes **0.0001ms** (Memory lookup).
In Microservices, `HTTP GET /users/1` takes **20ms** (Network serialization + TCP handshake + Latency).

You just made your basic operation **200,000x slower**.

### 2. The Distributed Tracing Nightmare
In a Monolith, if an error happens, you look at the **Stack Trace**. It tells you exactly line 42 failed.

In Microservices, User request -> Gateway -> Auth Service -> Order Service -> Payment Service (Error).
Where are the logs? You have to search 4 different servers.
*   **Fix**: You MUST implement **Distributed Tracing** (OpenTelemetry/Jaeger). Without it, you are flying blind.

***

## Part 3: The Diagnosis (The Distributed Monolith)

This is the worst architecture in existence.

It happens when you build a Village, but you still act like a Mansion.
*   **Symptom**: "I cannot deploy Service A because it requires Service B to be updated first."
*   **Symptom**: Service A reaches directly into Service B's database. (Breaking the #1 rule: Private Fridges).
*   **Symptom**: Massive API calls. To load the homepage, the frontend has to make 50 separate calls to 50 services.

If your services are "Micro" but tightly coupled, you have built a **Distributed Monolith**. You have all the slowness of Microservices with none of the independence.

***

## Part 4: The Resolution (When to Split?)

Don't split by size ("The code is too big").
Split by **Domain**.

### The Rule of Two Pizzas (Amazon)
If a team gets too big to be fed by two pizzas, split the team. Then split the software to match the team.

### The Breakdown Strategy

1.  **Start Monolith**. Always. It moves fast.
2.  **Split the Heaviest Component First**.
    *   Is "Image Processing" using 90% of CPU? Move *just that* to a separate service (Lambda/Worker).
    *   Leave the rest in the Monolith.
3.  **Split the Different Lifecycle**.
    *   Does the "Billing" module only change once a year, but the "Frontend" changes every day? Split Billing so you don't risk breaking payments when changing CSS.

***

## Final Mental Model

```
Monolith      -> A Mansion. Fast, easy to share, scary to renovate.
Microservices -> A Village. Slow communication, robust, easy to renovate individually.

Distributed Monolith -> A Village where everyone is handcuffed together. Hell on Earth.
```

**Unless you are scaling the ORGANIZATION (people), keep the MONOLITH (code).**
You are not Netflix. You don't need Netflix's problems.