Вы все это видели.

Стартап на три человека. Идея простая — агрегатор скидок в районных парикмахерских. Бэкенд еще не написан, но архитектура уже утверждена.

Конечно же, микросервисы. Конечно же, Kubernetes. Обязательно кафка для обмена сообщениями, потому что «нам нужна асинхронность». И база данных — непременно NoSQL, желательно шардированная, ведь мы готовимся к миллионам пользователей. Сразу. В первый день.

Проходит полгода.

Продукт не запущен. Деньги инвесторов (или личные сбережения фаундера) сгорают на оплату кластеров в облаке. Два сеньора, которых наняли за большие деньги, целыми днями настраивают CI/CD пайплайны и спорят о правильной гранулярности сервисов.

А бизнес‑задача? Она потерялась. Мы не решаем проблему пользователя, мы решаем проблемы, которые сами себе создали, выбрав инструменты не по размеру.

Синдром Гугла

Мы читаем инженерные блоги Netflix, Uber или Facebook. Мы восхищаемся их решениями. Они крутые. Они масштабные.

Но мы забываем одну деталь — у нас нет проблем Netflix.

У нас нет петабайтов трафика в секунду. У нас нет тысяч разработчиков, которые не могут коммитить в один репозиторий. У нас нет необходимости в географическом распределении данных по пяти континентам прямо сейчас.

Копируя архитектуру гигантов, мы копируем их сложность, но не получаем их выгоды. Мы берем инструмент, созданный для решения проблем масштаба, и применяем его там, где проблемы масштаба нет. Это как покупать фуру, чтобы возить пакет молока из магазина. Можно? Можно. Неудобно, дорого, парковаться негде.

Давайте будем честными. Часто выбор технологий диктуется не потребностями проекта, а желанием разработчика прокачать резюме.

Написать «поднял монолит на Django» — скучно. Написать «спроектировал event‑driven архитектуру на Go с gRPC и Kubernetes» — звучит дорого.

Разработчик хочет играть с новыми игрушками. Ему скучно писать CRUD‑ы. Ему хочется челленджа. И если бизнес не дает сложных задач, разработчик придумывает сложность в архитектуре.

В итоге проект становится полигоном для обучения. За счет работодателя.

Цена сложности

Каждый лишний сервис — это налог. Налог на отладку. Налог на мониторинг. Налог на деплой.

В монолите, если что‑то сломалось, вы смотрите один лог. В микросервисах вы играете в детектива, пытаясь понять, где именно в цепочке из десяти вызовов потерялся пакет и почему сервис А думает, что транзакция прошла, а сервис Б — что нет.

Сложность системы растет не линейно, а экспоненциально с каждым новым компонентом.

Скучные технологии — это хорошо

Я люблю скучные технологии.

PostgreSQL. Python, PHP или Java. Старый добрый REST. Монолитная архитектура.

Знаете, почему? Потому что они предсказуемы. Потому что на StackOverflow есть ответы на 99% вопросов. Потому что нового разработчика можно ввести в проект за два дня, а не за два месяца изучения схемы взаимодействия сервисов.

Бизнесу (особенно на старте) плевать на красоту вашего графа зависимостей. Бизнесу нужно проверить гипотезу. Быстро. Дешево.

Если ваш монолит однажды не справится с нагрузкой — я вас поздравляю. Это называется «успех». У вас есть пользователи, у вас есть деньги. И вот тогда, имея ресурсы и понимание узких мест, вы начнете распиливать его на сервисы. Осознанно.

А пока у вас 100 пользователей в день — просто напишите код, который работает.

Не бойтесь быть простыми. Сложность продать легко. Простоту создать трудно.