Когда вы НЕ должны использовать микросервисы?

Question

Accepted Answer

Микросервисы часто являются **неправильным** выбором для начала. Общее правило — **"сначала монолит"**: начните с хорошо структурированного монолита и извлекайте сервисы только когда у вас есть конкретная причина.

## Избегайте микросервисов когда

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

## Стоимость преждевременного разделения

Перемещение вызова метода внутри процесса на сетевой вызов добавляет задержку, режимы отказа, сериализацию и единицу развёртывания. Если границы неправильные, вы платите всё это **и** по-прежнему должны рефакторить через сервисы.

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

## Лучший путь

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

## Почему это важно

Большинство команд, которые слишком рано принимают микросервисы, становятся медленнее, а не быстрее, потому что они берут на себя затраты распределённых систем до того, как они понадобятся.

Сохранение границ внутри монолита сначала позволяет вам дёшево изучить домен и разделить вдоль правильных швов позже.