>_
EngineeringNotes
← Back to System Design

Monolith vs Microservices

A Complete System Design Guide. Understand the trade-offs, architecture complexities, and when to use which pattern.

1. What is a Monolith?

  • All business logic lives in a single codebase
  • Typically deployed as one unit
  • Components are tightly coupled

Important Correction

It is NOT necessarily one machine! You can horizontally scale a monolith (e.g., multiple instances behind a load balancer).

Example Structure
Client
Load Balancer
Instance 1
Instance 2
Instance 3
Shared Database

2. Microservices

  • Splits system into independent business capabilities
  • Each service has its own logic and often its own database
  • Communicates via network (HTTP, gRPC, messaging)
Example Structure
Client
API Gateway
Payment Svc
Payment DB
Order Svc
Order DB
User Svc
User DB

Common Misconceptions (Very Important)

Myth 1: Monolith = Single Server
Reality: Can scale horizontally. You can put load balancers in front of multiple monolith instances.
Myth 2: Microservices = Many Tiny Functions
Reality: Each service = complete business unit. They aren't just single AWS Lambdas.
Myth 3: Microservices = Always Better
Reality: Adds massive complexity. Microservices shift complexity from code to infrastructure.

Deep Comparison (Beyond Basics)

4.1 Architecture Complexity

FactorMonolithMicroservices
SetupSimpleComplex
DeploymentSingle UnitDistributed
DebuggingEasierHard (network involved)
ObservabilityBasicNeeds tracing/logging infra

4.2 Performance

Monolith
Function calls (in-memory)✅ Fast
Microservices
Network calls (HTTP/gRPC)❌ Latency + failures
Hidden costs: Serialization/deserialization, Network retries, Timeouts.

4.3 Scalability

Monolith

Scale the entire system.

Inefficient if only one part is heavy
Microservices

Scale specific services independently.

Much more efficient
👉 Example: Chat system load ↑ → scale only chat service.

4.4 Team Structure (CRITICAL)

This is where microservices truly shine in the real world.

Monolith Teams
  • Tight coordination needed
  • Constant merge conflicts
  • Release bottlenecks
Microservices Teams
  • Teams own services independently
  • Faster, uncoordinated releases
Aligns perfectly withConway's Law

"System design mirrors team structure."

4.5 DB Design

Monolith
  • Single Database
  • Easy JOINs
  • Strong consistency
Microservices
  • Database per service
  • No JOINs across services
Must use APIs or Events. Leads to Event-driven architecture.

4.6 Data Consistency

MonolithACID transactions (Easy)
Microservices❌ Distributed TX (Hard)Use:Saga Pattern, Eventual consistency

4.7 Failure Handling

Monolith: One failure = entire system crash.

Microservices: Partial failure possible. Requires Circuit Breakers, Retries, Timeouts.

👉 Example: User service down → Payment can still work if decoupled.

4.8 Observability (Often ignored in interviews!)

Monolith

Logs are in one place. Easy to track a request.

Microservices

You desperately need:

  • • Distributed tracing
  • • Central logging
  • • Metrics system
Tools: Jaeger, Prometheus, ELK Stack

Advantages & Problems

Monolith Advantages

  • Simpler to build & deploy
  • Faster execution (no network overhead)
  • Easier debugging
  • Strong data consistency
Great for: Startups, Small teams.

Monolith Problems (Advanced)

  • Scaling inefficiency (must scale all)
  • Tight coupling
  • Slower innovation / merge conflicts
  • Codebase can become a "Big Ball of Mud"
  • Risky, all-or-nothing deployments

Microservices Advantages

  • Independent scaling
  • Independent deployments
  • Fault isolation
  • Better team autonomy
  • Tech flexibility (Polyglot programming)

Microservices Problems

  • Distributed system complexity
  • Network failures & latency
  • Data inconsistency
  • DevOps overhead
  • Hard debugging
The Real Truth: Microservices shift complexity from code to infrastructure.

When to Choose What?

🟢 Choose Monolith When:

Small team (≤10 engineers)Early-stage startupProduct not yet validatedFast iteration is needed
Example: Stack Overflow

🔵 Choose Microservices When:

Large complex systemMultiple independent teamsHigh scalability needsIndependent deploy needed
Examples: Netflix, Google, Facebook

The Hybrid Approach (Most Realistic)

Modern systems evolve. You don't jump straight to microservices.

MonolithModular MonolithMicroservices

This gradual extraction is called the Strangler Fig Pattern.

Interview Strategy

"Should we use Monolith or Microservices?"

Always start with Monolith. Tell the interviewer:

"I would start with a monolith. As the system scales and team size grows, I will gradually extract services based on scalability and independent deployment needs."

Golden Insight

Microservices are not about scaling systems.

They are fundamentally about scaling teams and development speed.