Вопросы на собеседовании по микросервисам

Вы читали названия паттернов, можете процитировать, что делает circuit breaker, но всё равно не понимаете, что именно слушает комиссия. В этом разделе перечислены четыре области, которые оценивают интервьюеры, в том порядке, в котором их обычно проверяют. Каждая из них на самом деле вопрос на суждение, замаскированный под вопрос на знание терминов.

• Декомпозиция. Где проводить границу и почему именно там? Интервьюеры хотят видеть границу, проведённую по бизнес-функциям или владению данными, а не по техническим слоям.
• Взаимодействие. Синхронный запрос-ответ или асинхронные события, и что ломается в каждом случае. Им нужен компромисс, а не предпочтение.
• Данные. Одна база данных на сервис означает отсутствие межсервисных join и распределённых транзакций. Как всё же сохранить корректность системы?
• Эксплуатация. Развёртывание, версионирование, трассировка и то, что происходит глубокой ночью, когда один сервис не упал, а просто стал медленным.

Обратите внимание: ни один из этих вопросов не про фреймворк. Кандидат, объясняющий, почему он отделил оформление заказа от склада, всегда наберёт больше баллов, чем тот, кто перечисляет аннотации.

Это вопросы, с которых начинается большинство раундов по микросервисам, и вот что интервьюер на самом деле проверяет за каждым из них.

• Как бы вы разбили этот монолит на сервисы? Проверяют, режете ли вы по бизнес-функциям и владению данными или по слоям controller, service и repository. Второй вариант ответа даёт распределённый монолит.
• Как два сервиса общаются друг с другом? Проверяют, можете ли вы назвать цену каждого варианта: синхронные вызовы дают простую ментальную модель, но связывают доступность сервисов, асинхронные события разрывают эту связь и дают итоговую согласованность, которую придётся объяснять владельцу продукта.
• Что такое распределённый монолит и как его избежать? Проверяют, понимаете ли вы, что сервисы, которые обязаны разворачиваться вместе, на самом деле не разделены.
• Каким должен быть размер сервиса? Проверяют, что вы не хватаетесь за конкретное число. Размер определяется границей и командой, которая ей владеет.
• Нужен ли API-шлюз и что он делает? Проверяют, умеете ли вы отделить маршрутизацию, аутентификацию и ограничение частоты запросов от бизнес-логики.
• Как сервисы находят друг друга? Проверяют базовое знакомство с service discovery и то, почему жёстко прописанные хосты ломаются в масштабируемой среде.

Проговаривайте компромисс вслух в каждом ответе. Комиссия не может начислить баллы за сравнение, которое вы сделали молча, про себя.

Именно на этом раунд выигрывают или проигрывают, потому что у этих вопросов нет чистого ответа, а кандидаты тянутся за заученным.

• Как вы поддерживаете согласованность данных между сервисами? Сначала назовите ограничение: межсервисной транзакции не существует. Затем опишите сагу, хореографическую через события или управляемую координатором, и прямо скажите, что система в итоге согласована, и что видит пользователь в этом промежутке.
• Что происходит, если нижестоящий сервис работает медленно? Таймауты, повторы с задержкой и circuit breaker, чтобы медленная зависимость не исчерпала пул потоков. Медленно хуже, чем недоступно, и то, что вы это говорите, показывает продакшен-опыт.
• Как сделать повтор безопасным? Идемпотентность. Ключ идемпотентности на пути записи, чтобы повторённый платёж списался только один раз.
• Как вы обрабатываете частичный сбой в многошаговом процессе? Компенсирующие действия, а не откат. Объясните, как выглядит возврат средств или отмена бронирования.
• Как вы отлаживаете запрос, затронувший шесть сервисов? Распределённая трассировка с correlation ID, который передаётся через каждый переход, плюс структурированные логи и метрики.

Бэкенд-инженер, проходивший собеседование на роль L5 в платформенной команде крупного облачного провайдера, получил вопрос про сагу и ответил на него с ходу, терминами паттернов, ни разу не упомянув, что увидит клиент. Уточняющий вопрос, что показывает страница заказа в окне несогласованности, и есть тот вопрос, который на самом деле решает исход раунда. Готовьте второй ответ, а не только первый.

Другие банки вопросов по ролям и темам собраны в разделе вопросы на собеседовании по ролям.

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

Выберите один хорошо знакомый вам процесс, оформление заказа или регистрацию, и вслух опишите всю декомпозицию: границу, выбор способа взаимодействия, историю согласованности, историю сбоев. Делайте это, пока не перестанете начинать предложения заново. Эти же вопросы можно проговорить с AI-интервьюером, который задаёт уточняющие вопросы и даёт отвечать голосом, в режиме mock interview, а это ближе к реальному собеседованию, чем перечитывание заметок.

Aaron Cao, основатель SubcueAI, построил режим практики вокруг именно этого разрыва, а не вокруг подачи контента. Списки вопросов есть в свободном доступе повсюду; кандидатам не хватает повторений произнесения ответа, пока кто-то ждёт. Во время настоящего собеседования десктоп-приложение и боковая панель браузерного расширения могут показывать структурированные подсказки прямо во время речи интервьюера, хотя отрепетированное объяснение всегда лучше того, которое вы читаете впервые. Что помощник делает и чего не делает, описано на странице обзор продукта.