Есть вопрос, который в IT почти не задают. Все знают: микросервисы лучше. Монолит - это легаси. Надо дробить. Надо масштабировать. Надо автономию команд. Это - мантра. Её повторяют на конференциях. Пишут в вакансиях. Вкладывают в архитектурные решения.

Но почему никто не спрашивает: а когда монолит лучше? Не "был лучше в 2005". А сейчас. В конкретной системе. В конкретной команде. В конкретном продукте. Где граница. После которой монолит перестаёт работать. И до которой он работает лучше, чем любая распределённая система.

Граница есть. И она не про размер. Не про нагрузку или деньги. Она про сложность. Которую можно удержать в голове.

У монолита есть свойства. Он быстрый. Потому что вызов - это функция. А функция не идёт по сети. Она не падает. Не таймаутится. Не требует ретраев. Она просто выполняется или не выполняется. Но не "где-то там", а тут - все достаточно прозрачно. У микросервисов вызов - это сеть. А сеть - это физика. Даже быстрая и надёжная, но физика. И если цепочка короткая - монолит выигрывает. Просто потому, что нет накладных расходов.

Монолит проще. Одна база. Один процесс. Одна точка входа. Одна команда. Не надо договариваться о контрактах. Не надо версионировать API. Не надо синхронизировать релизы. Просто код. И одна ответственность. И если команда маленькая - это работает "на ура". Лучше, чем любая оркестрация.

Монолит предсказуем. Он не масштабируется горизонтально. Но если спрос не растёт - горизонтальное масштабирование не нужно. А если спрос падает - не нужно платить за лишние экземпляры. Потому что экземпляр один. И он либо справляется, либо нет. Без промежуточных состояний.

Но есть точка, где монолит начинает проигрывать. И эта точка - не в количестве строк. Не в количестве пользователей. Не в количестве транзакций. Она в количестве изменений, которые нужно вносить одновременно. Если изменения касаются одной части - монолит справляется. Если разных - он требует пересборки всего. А это риск. Это долго, это подчас страшно. И тогда появляется соблазн: давайте разделим.

И вот здесь - ключевой момент. Разделение - не про технологию. Оно про границы, которые нужно провести. Где заканчивается одна ответственность и начинается другая? Где одна команда может работать, не зная, что делает другая? Где изменение в одной части не ломает другую? Я сейчас не про сервисы. Это про людей. Про то, сколько людей может работать параллельно, не мешая друг другу. Монолит работает, пока система помещается в голову одной команды. Пока один человек (или даже несколько) могут держать в уме всю картину, все связи, все зависимости и все последствия.

Как только перестаёт помещаться - монолит начинает трещать. Не потому что плохой, а потому что голова - не бесконечная, а система - больше, чем голова. И тогда - только граница. Не "когда монолит плохой". А "когда он перестаёт быть удерживаемым". Это - не про размер. Это - про сложность. Про количество связей. Про количество изменений. Про количество людей, которые должны договориться. И если не договорятся - монолит не спасает. Он просто становится медленным. И хрупким.

Знаете что напоминает? СССР. Я сейчас со всем искренним должным уважением.

Но СССР сейчас у меня не как политика. Как архитектура - монолит без границ. Центр, который должен был держать всё. Потому что автономии не было. Не потому что злые, а потому что архитектура не предполагала. Монолит не предполагает границ. Он предполагает центр. А центр не может держать двадцать два миллиона квадратных километров. Физически. Просто потому что сигнал идёт долго. А обратная связь - ещё дольше.

К чему я тут прописные истины пишу? Возник сегодня вопрос про "микросервис vs монолит" в одном проекте. Переписывать "не хотелось" команде. Пришлось объяснять на пальцах не "что лучше", а "где граница". Так и пост родился.

Граница - не в технологии, размере или нагрузке. Она в сложности, которую можно удержать одной головой, одной командой, одним центром.

Как только сложность превышает пора делить. Не потому что модно, а потому что иначе - не удержать. Ни в голове, ни в руках, ни в системе.

Чек-лист - в комментарии.