Дорогая ошибка
Микросервисы одна из самых переоценённых вещей в разработке. Команда начинает проект и сразу: «давайте разобьём на сервисы, будет масштабируемо». Звучит логично. На практике это premature scaling, ты масштабируешь то, чего ещё нет. Нет нагрузки, нет команды, нет проблем. Но уже есть сервисы, взаимодействие между ними и инфраструктура, которую кто-то должен поддерживать.
Мой кейс
У меня был конкретный пример. Нужно было сделать систему рекомендаций для интернет-магазина. Идея: вынести в отдельный микросервис на Go, чтобы можно было менять провайдера, чтобы было «гибко». Сервис ходил во внешнее API, фильтровал данные, проверял наличие товаров. Ушло около трёх недель.
В следующей версии backend мы просто сделали это внутри основного приложения на PHP. Без отдельного сервиса, без лишней инфраструктуры. И в этот момент стало очевидно: микросервис был лишним. Думали «микросервисы = правильно», вместо того чтобы думать: «это сейчас решает проблему?»
Когда оправдано
Это не значит, что микросервисы не нужны. Вот противоположный кейс: мы принимали аудио с клиентов чанками, была высокая нагрузка на I/O, и PHP здесь объективно не справлялся. Мы вынесли один endpoint в отдельный сервис на Python (FastAPI). Это было оправдано: конкретная проблема, техническое ограничение, точечное решение.
Микросервисы оправданы, когда есть конкретный bottleneck, разные типы нагрузки, необходимость изоляции и команда, которая это поддержит. Не надо резать систему на 10 сервисов, часто достаточно одного дополнительного процесса.
Главный вопрос
Микросервисы дают гибкость, но стоят дорого: время на разработку, сложность деплоя, мониторинг, логирование, сетевые проблемы, синхронизация данных. Если нет DevOps-практик и опыта, ты начинаешь тратить больше времени на инфраструктуру, чем на продукт.
Главный вопрос всегда один: это сейчас нужно или это страх будущего? Зрелость разработчика это не умение строить сложные системы. Это умение не усложнять без причины.
