С какими протоколами передачи данных вы работали
Что проверяют
Выбираете ли вы транспорт под задачу и понимаете ли, чем за него платите. Список названий тут стоит мало, ценится объяснение: почему между своими сервисами gRPC, а наружу обычный HTTP, и что от этого меняется в коде.
Как отвечать
Идите по вариантам и на каждом называйте цену:
- HTTP и JSON. Понятен всем, отлаживается одной командой в терминале, проходит через любые прокси. В Go важна деталь: у клиента по умолчанию нет общего таймаута, и повисший запрос держит горутину, пока сервер не сжалится;
- gRPC поверх HTTP/2. Контракт в схеме, генерация кода, потоки в обе стороны, мультиплексирование в одном соединении. Платите отладкой и балансировкой: соединение долгое, обычный балансировщик распределяет соединения, а не запросы, поэтому нужна клиентская балансировка;
- WebSocket. Двусторонний обмен ценой состояния на сервере, а состояние мешает масштабированию;
- брокеры сообщений. Это уже не вызов, а развязка по времени: доставка обычно не менее одного раза, значит обработчик обязан быть идемпотентным;
- голый TCP или UDP. Свой формат кадра, ручная сборка сообщения из кусков, буферизованное чтение. Оправдано редко.
Через весь ответ протяните две привычки: дедлайн через context на каждый внешний вызов и аккуратное закрытие тела ответа.
Где спотыкаются
Берут клиент по умолчанию без таймаутов. В нагруженном сервисе это растущее число горутин, висящих на мёртвых соединениях, и память, которая не возвращается.
Второе: не дочитывают и не закрывают тело ответа. Соединение не возвращается в пул, клиент открывает новое на каждый запрос и рано или поздно упирается в лимит дескрипторов.
Третье: объясняют скорость gRPC только двоичным форматом. Основной выигрыш даёт постоянное соединение и мультиплексирование, на редких вызовах разница почти незаметна, зато появляется схема, которую нужно версионировать.