Вопросы на собеседовании архитектора ПО

Пример сильного ответа

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

• Показан критерий выбора, а не мода
• Есть конкретный результат с цифрой
• Упомянута фиксация решения и условия пересмотра

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Границы выделяю по бизнес-возможностям, а не по слоям кода или таблицам. Начинаю с карты домена: где меняются правила, кто владеет данными, какие сценарии обязаны быть транзакционно целостными. Всё, что должно меняться вместе, оставляю в одном сервисе, а коммуникацию строю через события и явные контракты. Организационный фактор тоже учитываю: одна команда — один сервис, иначе границы быстро размываются. В одном проекте такая декомпозиция сократила количество синхронных вызовов примерно на 40 процентов и убрала общие базы данных. Отдельно проверяю границы на сценариях отказа: если падение соседа ломает половину продукта, граница проведена неверно.

• Ясен принцип декомпозиции по домену
• Приведены цифры и отказ от общих баз
• Учтён организационный и эксплуатационный фактор

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Чаще всего применяю CQRS и событийную архитектуру — там, где чтение и запись сильно расходятся по нагрузке. В одном сервисе это позволило держать пиковые чтения без блокировок и снизить время ответа примерно на треть. Стратегию и адаптер использую для интеграций с внешними системами: несколько провайдеров за одним интерфейсом, подмена без правок бизнес-логики. Сага выручает в распределённых сценариях, где нужны компенсации вместо общей транзакции. Circuit breaker и bulkhead — обязательный минимум для устойчивости. Паттерн выбираю под проблему, а не наоборот, и всегда проговариваю цену решения: где кэш, где отложенная согласованность, как это увидит поддержка.

• Паттерны привязаны к конкретным задачам
• Есть измеримый эффект на время ответа
• Показано понимание цены каждого решения

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Переписывать с нуля — самый дорогой и рискованный путь, поэтому работаю через постепенное обёртывание. Сначала фиксирую поведение системы тестами на ключевых сценариях, чтобы изменения были безопасными. Затем выношу наружу швы: интерфейсы, адаптеры, слой доступа к данным, и переношу функциональность небольшими порциями, сохраняя работоспособность продукта на каждом шаге. В одном проекте такой подход дал вынос трети логики за пару кварталов без остановки релизов и без простоев. Важно заранее договориться о метрике успеха и не смешивать миграцию с новыми фичами.

• Отказ от большого переписывания обоснован
• Показан пошаговый безопасный подход
• Есть результат с цифрой и метрикой

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Нефункциональные требования — это требования к качеству системы: производительность, надёжность, безопасность, масштабируемость, доступность, сопровождаемость. Подход такой — сначала понять контекст: интервью со стейкхолдерами, разбор инцидентов и текущих метрик, чек-листы по типовым атрибутам качества. Дальше перевожу пожелания в измеримые критерии: например, время отклика на 95-м перцентиле, число запросов в секунду, время восстановления. На одном проекте с пиковой нагрузкой порядка пяти тысяч запросов в секунду мы зафиксировали целевые показатели и снизили число инцидентов примерно на треть за квартал. Обязательно согласую приоритеты: не всё можно сделать одновременно.

• Сначала даёт определение, потом показывает конкретный процесс сбора.
• Переводит пожелания в измеримые метрики — это язык архитектора.
• Есть цифры результата: нагрузка и снижение инцидентов.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Я использую ADR — короткие записи, по одной на решение. Шаблон простой: контекст, рассмотренные варианты, выбранный вариант, последствия и статус. Храню их в том же репозитории, что и код, рядом со схемами, чтобы они не отставали от реальности. Обсуждение выношу в pull request: автор пишет, архитектурная группа комментирует, дальше решение принимается или отклоняется с обоснованием. На одном проекте около 40 таких записей сократили онбординг нового инженера примерно с трёх недель до одной и сняли половину повторных споров на ревью. Отдельно помечаю устаревшие решения, чтобы их не тянули в новые сервисы.

• Показан конкретный рабочий артефакт и процесс, а не общие слова
• Есть цифра: 40 записей и сокращение онбординга с трёх недель
• Видно, что документация живёт в репозитории и не отстаёт от кода

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Выбор отталкивается от требований. Синхронный вызов уместен, когда нужен немедленный ответ пользователю и понятная обработка ошибки: например, проверка прав или чтение баланса. Асинхронно делаю там, где важнее устойчивость и развязка по времени: события, интеграции, тяжёлая обработка. Правило простое: если вызывающий не может продолжать без результата — синхронно, если может — событие. Рабочий смешанный вариант: синхронно принять команду, вернуть идентификатор и дальше обработать асинхронно. На одном сервисе переход на события убрал зависимость от чужого SLA и сократил время ответа примерно вдвое — с 800 до 400 миллисекунд на пике.

• Дан критерий выбора, а не просто перечисление вариантов
• Есть гибридный сценарий, который показывает зрелость мышления
• Конкретный результат: снижение времени ответа вдвое

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Kafka использую как транспорт событий с ключом по идентификатору сущности: тогда события одной сущности попадают в одну партицию и порядок сохраняется. Число партиций подбираю по целевому throughput с запасом на рост. Consumer groups дают горизонтальное масштабирование: у каждой группы свой офсет, поэтому несколько потребителей читают один топик независимо. Гарантии — at least once с идемпотентной обработкой: дедупликация по идентификатору события и идемпотентные записи, коммит офсета только после успешной обработки. На одном потоке порядка 5 миллионов событий в сутки проходило через группу из шести потребителей, и повторные доставки не ломали данные.

• Названы партиции, группы и гарантии с реальной практикой
• Идемпотентность показана как часть контракта, а не как костыль
• Есть масштаб: 5 миллионов событий в сутки

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Базовая идея — не тянуть одну транзакцию через несколько сервисов, а сделать шаги идемпотентными и завершаемыми. Использую сагу: локальная транзакция в сервисе плюс событие и компенсирующее действие при сбое. Плюс outbox: событие пишется в ту же транзакцию, что и данные, а публикуется отдельным процессом, поэтому данные и события не расходятся. Где нужна согласованность чтения, добавляю идемпотентные ключи и версионирование, а расхождения ловит регулярная сверка. На одном проекте такой контур убрал ручные разборы: доля инцидентов, связанных с расхождением данных, снизилась примерно на 80 процентов, а система сходится за секунды.

• Названы сага и outbox — узнаваемые практические паттерны
• Объяснено, как ловятся расхождения, а не только как их избежать
• Результат в цифрах: минус около 80 процентов инцидентов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Начинаю с модели доступа: какие запросы, какой объём, нужны ли транзакции и жёсткая схема. Для транзакционных данных с целостностью по умолчанию беру реляционную базу. Если профиль — быстрый доступ по ключу и большой поток, подходит key-value или документная. Полнотекстовый поиск выношу в отдельный поисковый движок, аналитику — в колоночное хранилище. Разные базы в одной системе оправданы, когда у сценариев действительно разные требования и есть команда, способная их эксплуатировать. На одном проекте рядом жили реляционная база и поисковый индекс: отчёты ускорились примерно в десять раз, а поддержка осталась в рамках двух человек.

• Выбор объясняется через модель доступа и требования
• Показана цена решения — нужна команда для эксплуатации
• Есть измеримый эффект: ускорение отчётов примерно в десять раз

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Начинаю с данных, а не с гипотез: снимаю метрики по каждому слою — балансировщик, приложение, кэш, база — и смотрю, где задержка растёт первой. Обычно узкое место одно, остальное — следствие. Дальше профилирую самые горячие эндпоинты и проверяю типовые причины: N+1 запросы, блокировки в базе, отсутствие кэша, синхронные вызовы там, где достаточно очереди. Решение выбираю по стоимости: сначала индексы и кэш, потом горизонтальное масштабирование, и только затем переписывание. В одном проекте такая последовательность подняла пиковую пропускную способность в четыре раза на том же железе.

• Показан метод, а не общие слова
• Есть измеримый результат на своём опыте
• Видно мышление от дешёвых решений к дорогим

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Показана логика приоритетов, а не список технологий
• Есть проверка гипотез на практике, учения и хаос-тесты
• Результат выражен понятной метрикой

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Долг переведён в измеримые критерии
• Показано умение договариваться с бизнесом
• Есть конкретный результат за период

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.