Monolith vs Microservices (Why This Question Usually Shows Up at the Wrong Time)

I’ve Seen This Question Come Too Early

I’ve seen teams ask:

“Should we start with microservices?”

This happened:

• before traffic
• before bottlenecks
• before even knowing what the system really was

Nothing was slow yet.
Nothing was breaking.

But complexity arrived anyway.

What Actually Broke First

It wasn’t scale.

It was:

• debugging across services
• unclear ownership
• network failures nobody expected
• local development becoming painful

The system wasn’t big.

It was just distributed.

The Real Problem With the Question

“Monolith or microservices?” assumes:

• structure comes before understanding
• architecture prevents future pain
• complexity is something you can choose early

In reality:

Architecture reacts to pressure.
It doesn’t prevent it.

What a Monolith Feels Like in Practice

A monolith means:

• one deployment
• one failure domain
• one place to debug

When something breaks:

• logs are nearby
• behavior is visible
• fixes are fast

Monoliths optimize for learning speed.

That matters early.

What Microservices Feel Like in Practice

Microservices mean:

• network calls everywhere
• partial failures
• retries, timeouts, circuit breakers
• coordination between teams

They shine when:

• teams need independence
• domains are stable
• scale is already proven

Microservices optimize for organizational scale not learning.

The Hidden Trade-Off

Microservices don’t remove complexity.

They move it.

From:

• code boundaries

To:

• runtime behavior
• failure modes
• deployment pipelines
• observability gaps

Nothing disappears.
It just gets harder to see.

⚠️ Common Trap

Trap: Choosing microservices to avoid future refactoring.

Microservices are refactoring; just slower, distributed, and harder to undo.

How This Connects to What We’ve Learned

• Graceful Degradation
  Becomes mandatory once systems are distributed.
  https://vivekmolkar.com/posts/graceful-degradation/

• Circuit Breakers & Timeouts
  Stop being “nice ideas” and become survival tools.
  https://vivekmolkar.com/posts/circuit-breakers/

• Sharding & Replication
  Often solve scale problems before microservices do.
  https://vivekmolkar.com/posts/sharding/

Monolith vs microservices is not a technology choice.
It’s an organizational one.

🧪 Mini Exercise

Before choosing architecture, ask:

1. What is changing most often right now?
2. Where does debugging hurt today?
3. What pressure actually exists?

If the answers aren’t clear, neither is the architecture.

What Comes Next

Once boundaries exist…

How do systems agree on what those boundaries mean?

Next: API Design — Contracts Over Code