Какие методы взаимодействия с бэкендом использовали кроме REST API

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

Для Java-разработчика это вопрос про интеграции: как сервисы общаются между собой и с клиентами, когда REST не подходит. Хотят услышать, по каким признакам вы выбирали протокол. Следом спрашивают про гарантии доставки в очередях или про балансировку gRPC.

Как отвечать

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

• gRPC: контракт в .proto, бинарный protobuf поверх HTTP/2, генерация стабов, четыре вида вызовов вплоть до двунаправленного стриминга. В Java это grpc-java, в экосистеме Spring есть проект Spring gRPC. Хорош для внутренних вызовов между сервисами с жёстким контрактом;
• GraphQL: Spring for GraphQL с @QueryMapping и @SchemaMapping, проблему N+1 снимает @BatchMapping поверх DataLoader. Уместен, когда разным клиентам нужны разные срезы данных;
• брокеры сообщений: Kafka через spring-kafka и @KafkaListener, RabbitMQ через Spring AMQP. Развязывают сервисы во времени, дают буфер под пики и событийную архитектуру;
• SOAP: JAX-WS или Spring Web Services, контракт в WSDL. Живёт в интеграциях с банками, госсистемами и старыми ERP, и новому сервису его часто диктует внешняя сторона;
• push к клиенту: WebSocket, в Spring часто со STOMP, и SSE через SseEmitter в MVC или Flux<ServerSentEvent<T>> в WebFlux.

Под каждый пункт держите свой пример: какой обмен, почему не REST, какие проблемы решали.

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

Не думают про гарантии доставки в Kafka. В типичной настройке spring-kafka получается at-least-once: сообщение может прийти повторно, и обработчик обязан быть идемпотентным, например через ключ дедупликации в базе.

Ставят gRPC за L4-балансировщик. Долгоживущее HTTP/2-соединение прилипает к одному инстансу, и нагрузка перестаёт распределяться. Нужна балансировка на L7 или на стороне клиента.

Не задают дедлайн на gRPC-вызов. По умолчанию его нет, и зависший сервис держит поток вызывающего сколько угодно долго, поэтому withDeadlineAfter на стабе обязателен.