Приходилось ли участвовать в разработке архитектуры сервисов самостоятельно или под менторством
Что проверяют
Какие архитектурные решения принимали вы, а какие приняли за вас. Вопрос мягко предлагает признать уровень участия, и честный ответ ценится выше раздутого.
Как отвечать
Сначала роль: реализовывал утверждённую схему, проектировал модуль внутри сервиса, отвечал за контракт сервиса целиком. Потом конкретика.
- Границы и слои. Деление по доменным модулям вместо пакетов по типам классов, тонкий контроллер, транзакционная граница на прикладном слое, а не в контроллере и не в репозитории.
- Взаимодействие. Синхронный вызов там, где ответ нужен прямо сейчас, событие в брокере там, где получатель может отстать. Чтобы событие ушло вместе с изменением данных, заводят таблицу исходящих сообщений: иначе оно уходит до фиксации транзакции или теряется после неё.
- Устойчивость. Таймаут на каждый внешний вызов, ограниченные повторы с паузой, размыкатель цепи, пул соединений под реальную конкурентность.
- Данные и совместимость. Миграции схемы отдельным инструментом, обратная совместимость контракта, версионирование ответа, продуманный откат релиза.
Хорошо, если назовёте требование, которое определило выбор: ожидаемая нагрузка, срок хранения данных, необходимость аудита изменений.
Где спотыкаются
Перечисляют стек вместо архитектуры: фреймворк, кэш, брокер, мониторинг. Это инвентарь. Архитектура начинается там, где звучит, почему кэш стоит именно здесь и что происходит, когда он протух.
Вторая ошибка: внешний вызов внутри транзакции. Соединение из пула держится, пока чужой сервис думает, и под нагрузкой пул заканчивается. Отправку письма или сообщения выносят за фиксацию.
Третья: распиливают монолит, потому что так делают. Отдельный сервис оправдан там, где у него свой темп изменений, своя нагрузка или своя команда. Без этого получается распределённый монолит, который всё равно выкатывается целиком.