Подходит ли gRPC при низкой частоте обращений и большом объеме данных
Что проверяют
Умеете ли вы выбирать протокол по профилю нагрузки, а не по моде. Ждут, что вы разложите вопрос на две части: что даёт gRPC при редких вызовах и что при больших телах, и назовёте цену решения, а не только плюсы.
Как отвечать
Про частоту: главный выигрыш gRPC в мультиплексировании HTTP/2 и дешёвой бинарной сериализации, и он заметен на потоке мелких вызовов. Если запросы редкие, выгода почти не видна, но и потерь нет: соединение держится долгоживущим, рукопожатие на каждый вызов не повторяется. Цена тут организационная: контракты в proto и кодогенерация, для отладки нужен grpcurl вместо curl, а прокси и балансировщики обязаны понимать HTTP/2.
Про объём: protobuf компактнее JSON, а серверный стриминг позволяет отдавать данные кусками, не собирая ответ целиком в памяти. Помните про ограничение размера сообщения: оно по умолчанию небольшое, и запрос падает с ResourceExhausted. Поднять лимит можно, но правильнее стримить. На текстовых данных заметно помогает сжатие.
Вывод формулируйте так: для внутреннего взаимодействия сервисов gRPC годится и в этом сценарии, стриминг закрывает объём, редкость вызовов ничего не ломает. Если же клиент внешний и публичный или команда не готова поддерживать контракты, выгода не окупит сложности, и обычный HTTP с потоковой отдачей окажется дешевле. Для очень больших файлов разумнее вернуть ссылку на объектное хранилище.
Где спотыкаются
Утверждают, что gRPC всегда быстрее REST. На мегабайтных телах время определяется сетью и сжатием, формат сериализации там уже почти не важен.
Не знают про предел размера сообщения и узнают о нём на проде. Бесконечно поднимать его опасно: сообщение целиком держится в памяти обеих сторон, и один клиент с большим ответом роняет сервис.
Забывают про эксплуатацию. Балансировка на транспортном уровне закрепляет долгое соединение за одним экземпляром, нагрузка перекашивается, новые поды остаются пустыми. Нужна клиентская балансировка или прокси уровня приложения.