## Как я вообще оказалась внутри чужого бэкенда В январе 2026 года ко мне пришёл бывший коллега. Он к тому моменту полтора года работал техлидом в сети фитнес-клубов, которая запустила своё мобильное приложение — расписание, оплата, личный кабинет, push про тренировки, синхронизация с носимыми устройствами. Приложение стабильно работало на 50 тысячах активных пользователей, оборот по подпискам — около 12 миллионов в месяц. Коллега спросил: «Можешь посмотреть наш стек со стороны и сказать, что мы делаем не так? У меня ощущение, что мы где-то переусложнили». Я согласилась — за фиксированную сумму за один день работы. Попросила доступ к репозиторию, схему базы, метрики с продакшена. К концу дня я составила список из семи пунктов «что у них хорошо» и трёх пунктов «что переделать». Пункт первый из «что у них хорошо» меня удивил больше всего: у них не было Kubernetes. ## Что я ожидала увидеть, и что увидела Я шла с предустановкой. Приложение на 50 тысяч активных пользователей, с платежами, push-уведомлениями, личным кабинетом, историей тренировок — это в голове сразу рисуется архитектура из учебника: API Gateway, четыре микросервиса (auth, schedule, payments, profile), брокер сообщений между ними, отдельный сервис для push, отдельный для интеграции с носимыми устройствами, Kubernetes для оркестрации, шлюз для API, база для каждого сервиса, два-три реплицированных storage для бэкапов. Я открыла их production-конфиг. Увидела три строки: один процесс на Node.js версии 20, база Postgres, CDN для статики. Точка. Никаких микросервисов. Никакого брокера. Никакого Kubernetes. Один процесс на восьми серверах за балансировщиком, одна база, одна папка со статикой в CDN. Push-уведомления — отдельный маленький воркер, который тянет очередь из той же Postgres. Синхронизация с носимыми устройствами — отдельный крон-скрипт, который раз в час забирает данные через API партнёра и кладёт в базу. Я перечитала их дашборд. 50 тысяч активных пользователей в месяц, среднее время ответа API 80 миллисекунд, аптайм 99.95 процента за последние полгода, размер базы 14 гигабайт, размер процесса в памяти 320 мегабайт. Это работало. ## Почему они выбрали простоту, а не модный стек За ужином коллега рассказал, как они к этому пришли. Когда проектировали, им в техсобесе на собеседованиях кандидаты рассказывали, как надо делать правильно: «монолит — это плохо, надо сразу на микросервисы, иначе потом будет сложно масштабировать». Команда из трёх разработчиков испугалась, что без микросервисов их сочтут непрофессионалами. Начали проектировать архитектуру с пятью сервисами. К концу третьей недели поняли, что не успевают к запуску. Позвали консультанта из большой компании, который посмотрел на их продукт, нагрузку и команду и сказал: «У вас три разработчика, 50 тысяч пользователей в перспективе, средний чек подписки 800 рублей. Вам монолит на Node.js, одна база, один процесс. Этого хватит на ближайшие два года. Когда выйдете на 300 тысяч пользователей и поймёте, что узкое место именно в архитектуре, тогда и будете разделять. До этого — вы просто будете тратить время на инфраструктуру, которая не нужна». Они выкинули черновик микросервисной архитектуры, за выходные собрали монолит, через три месяца запустились. ## Что мы, самозанятые, делаем не так, глядя на такие истории Когда я рассказала эту историю знакомому самозанятому разработчику, он сказал: «Ну это же корпорация, у них 50 тысяч пользователей, им нужна серьёзная инфраструктура. А у меня сайт-портфолио, мне вообще не о чем думать». Он прав в одном: для портфолио инфраструктура не нужна. Но он неправ в другом: та же самая логика «не добавляй сложность, пока не упёрся» применима к его сайту точно так же, как к приложению на 50 тысяч пользователей. Если у него одна страница, форма обратной связи и блок с кейсами — ему нужен статический сайт на любом бесплатном хостинге, без базы данных, без Node.js, без всего. Если он добавляет туда блог на собственной CMS с авторизацией, комментариями, тегами, поиском — ему нужна база. Если у него становится 10 постов в месяц и нужна модерация комментариев — ему всё ещё не нужен Kubernetes. Я видела, как самозанятые тратят по три-четыре недели на настройку CI/CD, Docker, автодеплой через Kubernetes, потому что им сказали «так делают профессионалы». Потом у них нет времени писать посты, вести клиентов, продавать. Они тратят по 8 часов в неделю на инфраструктуру, которая нужна была бы при десяти тысячах пользователей, а у них их двести. ## Три правила, которые я вынесла из этого разбора Первое. Считайте узкое место, а не возможный будущий размер. Если у вас 500 посетителей в день, и они приходят через 5 секунд — нет смысла оптимизировать до 2 секунд. Если они приходят через 30 секунд — есть смысл, но не через Kubernetes, а через CDN и нормальный хостинг. Второе. Переусложнение стоит дороже, чем недоусложнение. Написать монолит и потом выделить из него микросервис — это 2-3 месяца работы. Написать микросервисы и потом собрать из них монолит — это полгода переписывания. Идти от простого к сложному дешевле, чем от сложного к простому. Третье. Смотрите на цифры в дашборде, а не на статьи в Hacker News. Если ваш процесс 200 мегабайт в памяти, база 50 мегабайт, аптайм 99 процент — у вас всё в порядке. Не надо ничего переделывать, потому что кто-то в Твиттере написал, что монолит это legacy. ## Постскриптум Через полгода после моего разбора команда фитнес-клуба выросла до 80 тысяч пользователей. Их монолит по-прежнему работает. Единственное, что они добавили — второй реплицированный инстанс базы для бэкапов. Ни одного микросервиса. Когда они выйдут на 300 тысяч, им действительно придётся разделять. Но это будет через 3-4 года, и к тому моменту у них будет команда из 8-10 разработчиков, которая понимает, что и зачем она разделяет. Не потому что это «правильно по учебнику», а потому что их дашборд наконец покажет узкое место.