Какие прикладные протоколы используются в проекте
Что проверяют
Понимаете ли вы, какие протоколы стоят за вашим Java-сервисом и почему выбраны именно они. Следом обычно спрашивают, почему между сервисами gRPC, а наружу REST, и как вы обеспечиваете идемпотентность при повторах.
Как отвечать
Опишите проект по направлениям взаимодействия, у каждого пункта назовите библиотеку и причину выбора:
- HTTP наружу: REST на Spring MVC или WebFlux, JSON через Jackson, контракт в OpenAPI. Клиенты
RestClientилиWebClient,RestTemplateв новых проектах уже не берут; - между сервисами: gRPC поверх HTTP/2 с Protobuf, когда важны строгий контракт, генерация кода и стриминг. Или тот же REST, если команде так проще;
- сообщения: Kafka со своим бинарным протоколом поверх TCP, RabbitMQ по AMQP 0-9-1, в Spring это
spring-kafkaи Spring AMQP. Здесь стоит сказать про гарантии доставки и повторы; - реальное время: WebSocket, в Spring часто вместе со STOMP, или Server-Sent Events, если поток идёт только от сервера;
- инфраструктура: протокол PostgreSQL за JDBC-драйвером, OAuth 2.0 и OpenID Connect для авторизации, SMTP для почты, OTLP для отправки трасс и метрик.
Сильная часть ответа это компромиссы: почему не gRPC в браузер (нужен gRPC-Web или прокси), почему очередь, а не синхронный вызов, что делаете при таймауте. Для HTTP упомяните семантику методов: GET, PUT и DELETE идемпотентны, POST нет, поэтому для безопасного повтора платежа нужен ключ идемпотентности.
Называйте только то, с чем работали сами. Если MQTT был лишь в учебном проекте, так и скажите.
Где спотыкаются
Путают уровни: называют REST протоколом, а Kafka считают реализацией AMQP. У Kafka собственный протокол, и это влияет на выбор клиентов и прокси.
Перечисляют протоколы из учебника, которых в проекте не было. Первый же вопрос про уровни QoS в MQTT такой ответ разваливает.
Не знают, как gRPC ведёт себя за балансировщиком. Долгоживущее соединение HTTP/2 уходит на один экземпляр, и L4-балансировщик нагрузку не размазывает, нужна балансировка на уровне запросов или на клиенте.