Какие способы взаимодействия между сервисами используются: REST или другие интеграции?
Что проверяют
Для системного аналитика это вопрос не про определения, а про выбор: умеете ли вы по требованиям понять, какой способ интеграции подходит, и описать его так, чтобы разработчики сделали без догадок. Следом обычно просят рассказать про интеграцию из своего проекта: кто источник, кто потребитель и как обрабатывались ошибки.
Как отвечать
Разделите способы на синхронные и асинхронные, это главная ось выбора.
- REST: ресурсы, методы HTTP, коды ответа, обычно JSON. Контракт описывается в OpenAPI. Подходит, когда клиенту нужен ответ сразу;
- SOAP: XML-сообщения по строгому контракту WSDL и XSD, стандарты вроде WS-Security. Живёт в банках, госинтеграциях и старых корпоративных системах;
- gRPC: HTTP/2, контракт в
.proto, бинарная сериализация Protobuf, потоковые вызовы. Хорош между внутренними сервисами, из браузера напрямую без прокси не работает; - GraphQL: одна точка входа, клиент сам выбирает поля. Удобен фронтенду с разнородными экранами;
- брокеры сообщений (Kafka, RabbitMQ): отправитель не ждёт получателя, сервисы развязаны по времени и доступности. Контракт событий удобно описывать в AsyncAPI;
- вебхуки, файловый обмен, CDC: обратный вызов по событию, выгрузка по расписанию через SFTP, захват изменений из базы (например, Debezium).
Критерии выбора называйте явно: нужен ли ответ в моменте, объём и частота данных, допустимая задержка, гарантии доставки, кто владеет контрактом. В описании интеграции аналитик фиксирует не только поля, но и таймауты, повторы, идемпотентность (заголовок Idempotency-Key или бизнес-идентификатор), коды ошибок и версионирование.
Где спотыкаются
Считают REST любым HTTP с JSON. Эндпоинт POST /doAction с глаголом в пути это RPC поверх HTTP, и хорошо, если вы это различаете.
Описывают только успешный сценарий. Что делает система, если партнёр ответил 503 или молчит 30 секунд, остаётся за кадром, и каждый разработчик решает это по-своему.
Предлагают интеграцию через общую базу данных как самый простой вариант. Она связывает сервисы схемой таблиц, и любая миграция у одного ломает соседа.