When should you NOT use microservices?

Question

Accepted Answer

Microservices are often the **wrong** starting choice. A common rule is **"monolith first"**: begin with a well-structured monolith and extract services only when you have a concrete reason.

## Avoid microservices when

```text
✗ Small team — more services than people to run them
✗ Early-stage product — domain boundaries still shifting
✗ No CI/CD, monitoring, or tracing in place
✗ Low traffic — no real scaling pressure
✗ Simple domain — splitting adds cost, not value
```

## The cost of premature splitting

Moving an in-process method call to a network call adds latency, failure modes, serialization, and a deployment unit. If boundaries are wrong, you pay all that **and** still have to refactor across services.

```text
method call        →  microseconds, can't fail
network call       →  milliseconds, can time out, can be down
```

## Better path

```text
Start: modular monolith (clear internal boundaries)
  └─▶ Extract a service ONLY when:
         · it needs independent scaling, OR
         · a separate team needs independent deploys, OR
         · it needs a different tech/SLA
```

## Why it matters

Most teams that adopt microservices too early end up slower, not faster, because they take on distributed-systems overhead before they need it.

Keeping boundaries inside a monolith first lets you learn the domain cheaply and split along the right seams later.