Какие проблемы возникают при избыточном дроблении системы на микросервисы?

Микросервисы решают проблемы монолита, но у любой архитектуры есть цена. Когда сервисов становится слишком много, а их границы проведены не по бизнес-возможностям, а по техническим деталям, система превращается в распределённый монолит с сетевыми вызовами вместо вызовов методов.

Основные проблемы

• Сетевые задержки и каскадные отказы. Каждый вызов по сети в разы медленнее локального. Если для одной операции нужно 10 сервисов, задержки складываются, а падение одного ломает всю цепочку.
• Распределённые транзакции. Атомарность между сервисами не гарантируется, приходится использовать Saga, компенсации и eventual consistency, что усложняет код.
• Операционная нагрузка. Каждый сервис требует CI/CD, мониторинга, логирования, конфигурации и деплоя. Число сервисов растёт быстрее, чем команда.
• Сложность отладки. Ошибку нужно искать в распределённом трейсе, а не в стеке вызовов одного процесса.
• Дублирование и связность. Мелкие сервисы часто делят одни данные, что приводит к скрытой связанности и синхронизации схем.

Пример: слишком мелкий сервис

// Антипаттерн: сервис только для одной операции
app.get('/user-name', async (req, res) => {
  const user = await fetch(`http://user-service/users/${req.query.id}`);
  res.json({ name: user.name }); // лишний сетевой хоп
});

// Лучше: объединить в один сервис с бизнес-границей
app.get('/users/:id', async (req, res) => {
  const user = await userRepo.findById(req.params.id);
  res.json(user);
});

На практике правило простое: сервис должен соответствовать bounded context и владеть своими данными. Если два сервиса постоянно общаются синхронно и меняются вместе, их, скорее всего, стоит объединить.

Итог: дробить систему стоит только там, где это даёт независимость деплоя и масштабирования для конкретной команды. Иначе избыточная гранулярность превращает архитектуру в источник задержек, багов и операционной боли.