¿Cuándo NO debería usar microservices?

Question

Accepted Answer

Los microservices suelen ser la opción inicial **incorrecta**. Una regla común es **"monolito primero"**: comience con un monolito bien estructurado y extraiga servicios solo cuando tenga una razón concreta.

## Evite microservices cuando

```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
```

## El costo de la división prematura

Mover una llamada de método in-process a una llamada de red agrega latencia, modos de fallo, serialización y una unidad de implementación. Si los límites son incorrectos, paga todo eso **y** aún tiene que refactorizar entre servicios.

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

## Mejor camino

```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
```

## Por qué es importante

La mayoría de los equipos que adoptan microservices demasiado pronto terminan siendo más lentos, no más rápidos, porque asumen la sobrecarga de sistemas distribuidos antes de necesitarla.

Mantener los límites dentro de un monolito primero le permite aprender el dominio de manera económica y dividir a lo largo de las costuras correctas más adelante.