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