Microservices vs Monoliths: When to Choose What

The Question Nobody Answers Honestly

Every architecture discussion gravitates toward microservices as the “mature” choice. But after building both monoliths and distributed systems I’ve come to a more nuanced view: the right answer depends almost entirely on team size and traffic profile.

Start Monolithic (Almost Always)

A well-structured monolith is faster to build, easier to test, and simpler to deploy. For solo developers or small teams (1–5 engineers), the cognitive overhead of service boundaries, inter-service networking, and distributed tracing often costs more than it saves.

I’ve shipped a Laravel monolith that served 50k users/month with zero scaling issues — because vertical scaling is cheap and SQL is really fast.

# Deploying a monolith: one artifact, one pipeline
git push heroku main

Versus microservices, which require:

• Container orchestration (Kubernetes or ECS)
• Service discovery
• Distributed tracing (Jaeger, Zipkin)
• Per-service CI/CD pipelines
• API gateway

When Microservices Make Sense

Split when a specific domain has different scaling needs or different deployment cadences than the rest:

1. Your media processing pipeline needs 10× more CPU than your API — separate it.
2. Your notifications service is changing weekly while billing is stable — separate it.
3. Different teams own different domains and shipping velocity is blocked by merge conflicts.

┌──────────────────────────────────────────────┐
│  API Gateway (nginx/Kong)                    │
├───────────┬───────────┬──────────────────────┤
│  Auth     │  Catalog  │  Orders + Payments   │
│  Service  │  Service  │  Service             │
└───────────┴───────────┴──────────────────────┘

The Strangler Fig Pattern

You don’t have to rewrite everything. Extract services incrementally using the Strangler Fig pattern — route specific endpoints to new services while the monolith handles the rest. This is how most real migrations happen.

My Rule of Thumb

Start monolithic. Extract services when a specific boundary becomes a proven bottleneck or team ownership problem — not because it feels more “enterprise.”

Premature microservices is the new premature optimization.