Почему я отказался от микросервисов в пет-проекте

Полтора года назад я начал пет-проект — небольшой сервис для учёта личных расходов — и на радостях сразу нарисовал схему из семи микросервисов: авторизация, транзакции, категории, отчёты, уведомления, импорт банковских выписок и API-шлюз. Через месяц я всё это снёс и написал заново в виде одного монолитного приложения. Хочу объяснить, почему.

Соблазн красивой архитектуры

На работе я много имею дело с распределёнными системами, и мне казалось естественным переносить этот опыт на личный проект. Микросервисы выглядят солидно на диаграмме, каждый сервис — отдельная ответственность, всё по книжке. Проблема в том, что книжка писалась для команд из десятков человек и систем с реальной нагрузкой, а не для одного разработчика, который открывает ноутбук по вечерам два раза в неделю.

Где всё пошло не так

Первая проблема — локальная разработка. Чтобы просто проверить, как работает добавление транзакции, нужно было поднять пять контейнеров и убедиться, что все они видят друг друга по сети. Это отнимало больше времени, чем сама разработка фичи.

Вторая проблема — отладка. Ошибка «транзакция не сохранилась» могла быть в трёх разных сервисах, и чтобы её найти, приходилось прыгать между логами каждого из них. В монолите та же ошибка находится через один брейкпоинт.

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

Что получилось после переписывания

Одно Go-приложение с чёткими внутренними пакетами: auth, transactions, reports, notify. Каждый пакет знает только о своих интерфейсах, но всё это компилируется и деплоится как один бинарник. Локальный запуск — одна команда, без Docker Compose с семью сервисами.

Если проект когда-нибудь вырастет настолько, что отдельным частям понадобится независимое масштабирование — границы пакетов уже нарисованы, и выделить сервис из монолита будет относительно недорого. Но пока в этом нет практического смысла.

Вывод, который я стараюсь не забывать

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