Пост🏗 Модульный монолит vs микросервисы: что на самом деле важно

🏗 Модульный монолит vs микросервисы: что на самом деле важно Один из самых популярных архитектурных постов последних месяцев на HN (148 апвоутов, 151 комментарий) — статья «Modularity is what truly matters». Автор разбирает вечный холивар монолит/микросервисы и приходит к выводу, который многие чувствуют, но боятся сказать вслух: деление на сервисы — вторично. Модульность — первична. Ловушка, в которую попадают команды: решают «нам нужны микросервисы», нарезают систему на 15 сервисов, а потом обнаруживают, что 10 из них не могут работать друг без друга. Итог — распределённый монолит: все минусы обоих подходов и ни одного плюса. Сетевые вызовы вместо функций, eventual consistency вместо транзакций, и debug через три сервиса вместо одного стектрейса. Правильная последовательность: 1️⃣ Разберитесь в домене. Найдите реальные границы — где данные и логика слабо связаны друг с другом. 2️⃣ Сделайте модули внутри монолита. Отдельные папки/пакеты с чёткими интерфейсами и минимумом зависимостей. High cohesion, loose coupling. 3️⃣ Только потом, если конкретный модуль нуждается в независимом масштабировании или деплое — выносите его в отдельный сервис. Осознанно, а не «потому что Netflix так делает». Хороший тест: если два сервиса всегда деплоятся вместе, всегда падают вместе и не могут обработать запрос друг без друга — это не два сервиса. Это один сервис, которому зачем-то добавили сетевой вызов. Модульный монолит — это не шаг назад. Это честная архитектура, которая масштабируется в микросервисы, когда это действительно нужно, а не когда так написано в блоге. 🔗 Статья