Comments 3
Brainrot
Можете развить мысль, что вы имели ввиду?
Разбиение по слоям (анти-паттерн)
«Медленная разработка: Любое изменение требует полного регресса (везде ли всё поменяли) и согласования со всеми.»
«Масштабирование невозможно: При пиковой нагрузке на распродажах «падает» весь монолит, включая складской учёт т.к. передаётся слишком большой объём данных из-за разросшегося агрегата.»
«Когнитивная перегрузка: Новый разработчик должен понять все 50+ полей и методов, даже если работает только над каталогом.»
Абсолютно не согласен с этими утверждениями.
Команда из 10 человек может прекрасно развивать сложный монолит, тогда как для распределённой системы с той же логикой потребуются сотни людей. Разработка в монолите быстрее: только на согласование контрактов между сервисами уходят недели, плюс отладка взаимодействий.
Вместо одного лога и стектрейса — вам нужна распределённая трассировка по десяткам сервисов. Поиск причины сбоя превращается в детективное расследование.
Любой вызов теперь уязвим к таймаутам, сетевому лавинообразованию, проблемам DNS. Вы тратите больше времени на написание устойчивого к сбоям клиента, чем на бизнес-логику.
Независимое развёртывание — миф, если изменение API одного сервиса требует синхронного обновления трёх других. Версионирование API, устаревшие клиенты, graceful degradation — это отдельная инженерная дисциплина.
Масштабирование более чем возможно. Появились распределённые SQL-базы данных нового поколения, такие как YugabyteDB, CockroachDB, Google Spanner. Они предлагают строгую согласованность, горизонтальное масштабирование на уровне данных и распределённые ACID-транзакции — всё то, ради чего мы дробили монолит и отказывались от транзакционности.
В мире микросервисов разработчику необходимо понимать не меньше, но только он не может быстро посмотреть код, который происходит где-то там за границами сервиса
Микросервисы это не способ борьбы со сложностью, это про другое: разный технологический стек, независимые команды с разными циклами разработки и деплоя (при условии что контракты не меняются), жесткие нормативные или юридические требования, четко выделенные ресурсоёмкие специфичные задачи.
Связь паттернов микросервисной архитектуры