Какие способы взаимодействия между сервисами используются: REST или другие интеграции?

Что проверяют

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

Как отвечать

Разделите способы на синхронные и асинхронные:

• REST поверх HTTP: стандарт для публичных и большинства внутренних API, контракт в OpenAPI. В Spring клиент это RestClient или WebClient, RestTemplate оставлен для старого кода, а декларативные клиенты удобно описывать через @HttpExchange;
• gRPC: HTTP/2 и Protocol Buffers, строгий контракт в .proto, кодогенерация, стриминг. Хорош внутри системы, хуже для браузера и отладки через curl;
• GraphQL: чаще между фронтендом и бэкендом, когда клиенту нужны разные срезы данных;
• SOAP: встречается в интеграциях с банками и госсистемами, новое на нём обычно не пишут;
• брокеры сообщений: Kafka через KafkaTemplate и @KafkaListener, RabbitMQ через Spring AMQP. Отправитель не ждёт получателя, нагрузка сглаживается, сбой одного сервиса не валит цепочку.

Правило выбора: синхронно, когда ответ нужен прямо сейчас для продолжения запроса; асинхронно, когда достаточно гарантии, что событие будет обработано.

Дальше про сбои. Синхронным вызовам нужны таймауты, повторы с экспоненциальной задержкой и circuit breaker, в Java это Resilience4j. Для событий нужен идемпотентный обработчик, потому что Kafka и RabbitMQ в типичной настройке доставляют «хотя бы один раз», и паттерн Transactional Outbox, чтобы запись в базу и публикация события не разъехались. Вместо распределённой транзакции используют сагу с компенсациями.

Где спотыкаются

Говорят, что SOAP безопаснее или транзакционнее REST. Безопасность обеспечивают TLS и токены, а распределённые транзакции через WS-стандарты на практике почти не используют.

Строят цепочку из пяти синхронных вызовов без таймаутов. Один медленный сервис занимает потоки у всех, кто стоит перед ним, и отказ расползается каскадом.

Отправляют событие в Kafka сразу после коммита в базу, без outbox. Падение между двумя действиями теряет событие, и расхождение никто не замечает.