Были ли сервисы в проекте и как они взаимодействовали
Что проверяют
Работали ли вы с системой из нескольких сервисов и понимаете ли, почему связи между ними устроены именно так. Следом обычно спрашивают, что происходит, когда один из сервисов недоступен, и как вы искали причину сбоя, прошедшего через несколько сервисов.
Как отвечать
Начните с карты: сколько сервисов, за что отвечал каждый, какой был ваш. Потом разберите связи по типам:
- синхронные: REST на FastAPI или Django REST framework, реже gRPC через
grpcio. Клиентhttpxилиrequests, и обязательно с таймаутом: уrequestsего по умолчанию нет, запрос может висеть бесконечно; - асинхронные: RabbitMQ (Celery,
aio-pika) или Kafka (aiokafka,confluent-kafka) для событий и фоновых задач. Объясните, почему здесь очередь: отправку письма ждать не нужно, а сервис уведомлений может лежать без вреда для заказа; - контракты: схема OpenAPI, которую FastAPI генерирует сам,
.protoдля gRPC, версионирование API; - надёжность: повторы с экспоненциальной задержкой (
tenacity), идемпотентные обработчики, потому что брокер обычно доставляет «как минимум один раз», паттерн outbox, чтобы запись в базу и публикация события не разъехались, саги вместо распределённых транзакций; - наблюдаемость: сквозной
trace_idв заголовках, OpenTelemetry, логи в одном формате.
Самая сильная часть ответа это история конкретного сбоя: что упало, как нашли, что поменяли. Цифры задержек и нагрузки берите свои.
Если проект был монолитом, скажите об этом прямо и расскажите, как он общался с внешним миром: платёжный шлюз, фоновые задачи на Celery, интеграции с чужими API. Можно добавить, как бы вы делили его на сервисы и почему не стали бы делить раньше времени.
Где спотыкаются
Перечисляют REST, gRPC и Kafka набором слов и не могут объяснить, почему в одном месте выбран синхронный вызов, а в другом очередь.
Не думают об отказах: нет таймаутов, повторов и идемпотентности, и при сетевой ошибке заказ создаётся дважды.
Рассказывают шаблонную историю с «ускорили отклик на 30%», а на вопрос, как это измеряли, ответа нет.