Получить доступ

Какой вопрос лучше всего определяет выбор между синхронным вызовом и событием через брокер?

MiddleПроектирование API
Ещё спрашивают так:
  • Когда использовать REST, а когда брокер сообщений?
  • Синхронное или асинхронное взаимодействие сервисов?
Коротко

Главный вопрос: нужен ли ответ немедленно, чтобы продолжить? Нужен — синхронный вызов (REST, gRPC). Не нужен — событие через брокер.

  • События снижают связанность: издатель не знает потребителей и работает, даже когда они лежат
  • Цена событий: согласованность в конечном счёте, нет немедленного ответа, обработка должна быть идемпотентной
  • Частая ошибка — синхронный вызов там, где хватило бы события: доступности перемножаются

А ещё Внутри синхронного: REST — наружу и в браузер, gRPC — между сервисами

Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.

Подробно

Синхронный вызов — клиент ждёт ответа. Нужен, когда результат требуется для продолжения: проверить остаток перед оформлением, получить цену, авторизовать платёж. Цена — временная связанность: если вызываемый сервис недоступен или медленный, страдает вызывающий; в цепочках доступности перемножаются.

Событие через брокер — издатель сообщает «произошло X» и продолжает. Потребители обрабатывают в своём темпе. Подходит для реакций, которые не нужны для ответа: отправить письмо, начислить бонусы, обновить поиск, аналитику. Плюсы: издатель не знает потребителей, новых можно добавлять без его изменения, отказ потребителя не мешает издателю, брокер сглаживает пики. Цена:

  • согласованность в конечном счёте;
  • доставка обычно «хотя бы один раз» — обработка обязана быть идемпотентной;
  • сложнее отлаживать и прослеживать (нужна трассировка через брокер);
  • публикация события должна быть согласована с изменением данных — outbox.

Третий вариант — команда через очередь (асинхронный запрос с ответом позже): длительные задачи, например генерация отчёта.

REST или gRPC для синхронного: REST — для внешних клиентов и браузера, понятный и кэшируемый; gRPC — между сервисами: бинарный протокол, строгая схема, потоковая передача, HTTP/2, но хуже для браузера и отладки руками.

Что хотят услышать

  • Критерий: нужен ли ответ немедленно.
  • Плюсы событий для связанности и надёжности.
  • Цена: итоговая согласованность, идемпотентность, outbox.
  • REST против gRPC для синхронных вызовов — плюс.

Частые ошибки

  • Делать синхронными все вызовы «для простоты».
  • Использовать события там, где пользователю нужен результат сразу.

Проверьте себя

Один верный вариант. Подумайте, потом откройте ответ.

Показать варианты и ответ
  • ✓Нужен ли вызывающему ответ прямо сейчас, чтобы продолжить работу
  • ✗Какой объём данных передаётся
  • ✗На каком языке написан вызываемый сервис
  • ✗Есть ли у команды опыт работы с Kafka

Что спросят дальше

  • Чем gRPC выигрывает у REST внутри периметра?
  • Почему при событиях обработка обязана быть идемпотентной?

Разбор темы

Связанные вопросы

Закрытая бета

Подсказки на собеседовании — в реальном времени

sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.

  • Промокод на 2 часа — сверх пробных 30 минут
  • Программа для Windows — скачать сразу, войти — через Яндекс ID или VK ID
  • Прямая связь с разработчиком: что улучшить — сделаем