Какие системы связи использовали?

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

Под «системами связи» у Java-разработчика почти всегда имеют в виду взаимодействие сервисов: синхронные вызовы и брокеры сообщений. Интервьюер хочет понять, работали ли вы с этим руками и почему в конкретном месте выбрали очередь, а не HTTP. Следом спрашивают про гарантии доставки и повторную обработку. Если по контексту речь о мессенджерах и трекерах команды, ответьте парой фраз и вернитесь к технике.

Как отвечать

Отвечайте от своих проектов: что связывали, чем и почему. Каркас:

• REST: Spring MVC или WebFlux на сервере, на клиенте RestClient, WebClient или декларативные интерфейсы с @HttpExchange, в старом коде RestTemplate и Feign. Скажите про таймауты, повторы и circuit breaker на Resilience4j;
• gRPC: внутренние вызовы с жёстким контрактом в .proto, бинарный протокол поверх HTTP/2, стриминг;
• SOAP: чаще всего интеграция с банками и госсистемами, JAX-WS или Spring Web Services, клиент генерируется из WSDL;
• Kafka: @KafkaListener из spring-kafka, порядок гарантирован только внутри партиции, масштабирование через группы потребителей;
• RabbitMQ: @RabbitListener, маршрутизация через exchange, ручное подтверждение, очередь для недоставленных сообщений;
• WebSocket и SSE: уведомления в реальном времени, Spring WebSocket со STOMP.

Сильный ответ содержит одну историю с решением. Например, синхронный вызов соседнего сервиса валил весь запрос при его падении; вы вынесли событие в Kafka, добавили outbox-таблицу, чтобы запись в базу и отправка не расходились, и сделали обработчик идемпотентным. Цифры и детали берите свои. Если брокеров в работе не было, так и скажите, а затем покажите, как устроили бы обмен и на что обратили бы внимание: это честнее пересказа документации.

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

Называют технологии без причины выбора. «Использовал Kafka» без ответа на «почему не REST» звучит как строчка из резюме.

Считают, что брокер доставляет ровно один раз. Рассчитывать нужно на at-least-once: дубли придут, и потребитель обязан их переживать.

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