Один вопрос про микросервисы, на котором палятся те, кто только читал статьи

Ты знаешь, что такое микросервисы. Ты читал статьи на Habr, смотрел доклады, может даже работал с парой сервисов на проекте. На собесе тебя спрашивают: «Когда микросервисы — плохой выбор?» И вот тут начинается тишина.

Вопрос

Формулировки бывают разные, но суть одна:

— В каком случае ты бы НЕ стал разбивать монолит на микросервисы?

Иногда мягче: «Какие минусы у микросервисной архитектуры?» Иногда жёстче: «У нас стартап, 3 разработчика, MVP на горизонте. Ты предлагаешь микросервисы. Убеди меня.»

Почему этот вопрос задают

Потому что индустрия наелась. В 2018–2022 каждый второй стартап пилил микросервисы «потому что Netflix так делает». Результат — команда из пяти человек обслуживает 12 сервисов, половина которых падает по ночам, а деплой занимает три часа.

Интервьюер хочет понять одну вещь: ты принимаешь архитектурные решения на основе контекста или на основе хайпа?

По данным Habr, типичный ответ «среднего разработчика» на вопрос о микросервисах: «Это лучше, чем монолит». Минусы? «Ну... сложнее писать». Всё. На этом собес для тебя фактически заканчивается.

Плохой ответ

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

Что не так:

• Нет контекста. Масштабируемость чего? У тебя 100 пользователей или 100 миллионов?
• Нет цены. «Сложнее деплоить» — это не минус, это отсутствие ответа. Сколько сложнее? Что именно усложняется?
• Нет альтернатив. Кандидат не знает про модульный монолит, service mesh, serverless — только «монолит vs микросервисы»

Такой ответ говорит интервьюеру: человек прочитал одну статью и запомнил слово «масштабируемость».

Хороший ответ

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

И дальше — конкретика:

1. Маленькая команда, ранний продукт. Три бэкендера не могут поддерживать 10 сервисов. Каждый сервис — это свой CI/CD, мониторинг, логирование, healthcheck. При команде до 5–7 человек модульный монолит даст ту же изоляцию кода без операционного оверхеда.

2. Сильная связанность данных. Если два «сервиса» постоянно ходят друг к другу за данными — это не микросервисы, это распределённый монолит с сетевыми задержками. Хуже обоих миров: сложность распределённой системы + связанность монолита.

3. Нет инфраструктуры. Микросервисы без Kubernetes (или аналога), без централизованного логирования, без трейсинга — это хаос. Операционная стоимость микросервисной архитектуры почти всегда выше, чем у монолита. Если у команды нет DevOps-культуры, начинать с микросервисов — значит тушить пожары вместо написания фичей.

Бонусом можно добавить: «Я бы рассмотрел модульный монолит как промежуточный шаг — чёткие границы модулей, но единый деплой. Если модуль перерастёт — выносим в сервис.»

Что на самом деле проверяют

Не знание определения. Его знают все. Проверяют три вещи:

Умение говорить "нет" технологии. Сеньор — это не тот, кто знает больше инструментов. Это тот, кто знает, когда инструмент не нужен. Если кандидат не может назвать случай, когда микросервисы вредят — он никогда не принимал архитектурных решений сам.

Понимание trade-off. Каждое решение в архитектуре — это обмен. Микросервисы дают независимый деплой, но забирают простоту отладки. Дают масштабирование отдельных компонентов, но добавляют сетевую сложность. Кандидат, который видит только плюсы, не работал с системой в проде.

Реальный опыт. Человек, который разбивал монолит или, наоборот, сливал сервисы обратно — расскажет про это с болью и деталями. Человек, который только читал — будет оперировать абстракциями.

Как подготовиться

Если у тебя нет опыта с микросервисами в проде, не паникуй. Вот что реально поможет:

Разбери один кейс глубоко. Возьми любой известный постмортем: Segment вернулся к монолиту, Shopify перешёл на модульный монолит. Прочитай, почему. Это даст тебе аргументы, которых нет у 90% кандидатов.

Нарисуй trade-off таблицу. Монолит, модульный монолит, микросервисы. По колонкам: размер команды, скорость деплоя, сложность отладки, стоимость инфраструктуры. Запомни не ответы, а логику выбора.

Подготовь свой вопрос. Когда интервьюер спросит про микросервисы — спроси в ответ: «А какой у вас размер команды и текущая архитектура?» Это покажет, что ты думаешь контекстом, а не шаблонами.

Если хочешь прогнать этот вопрос вживую и получить разбор своего ответа — Sobes AI задаст уточняющие вопросы так, как это сделал бы реальный интервьюер. Не просто «правильно/неправильно», а «окей, а что если команда вырастет в три раза за полгода?»