Какой вопрос лучше всего определяет выбор между синхронным вызовом и событием через брокер?
- Когда использовать REST, а когда брокер сообщений?
- Синхронное или асинхронное взаимодействие сервисов?
Главный вопрос: нужен ли ответ немедленно, чтобы продолжить? Нужен — синхронный вызов (REST, gRPC). Не нужен — событие через брокер.
- События снижают связанность: издатель не знает потребителей и работает, даже когда они лежат
- Цена событий: согласованность в конечном счёте, нет немедленного ответа, обработка должна быть идемпотентной
- Частая ошибка — синхронный вызов там, где хватило бы события: доступности перемножаются
А ещё Внутри синхронного: REST — наружу и в браузер, gRPC — между сервисами
Подробно
Синхронный вызов — клиент ждёт ответа. Нужен, когда результат требуется для продолжения: проверить остаток перед оформлением, получить цену, авторизовать платёж. Цена — временная связанность: если вызываемый сервис недоступен или медленный, страдает вызывающий; в цепочках доступности перемножаются.
Событие через брокер — издатель сообщает «произошло X» и продолжает. Потребители обрабатывают в своём темпе. Подходит для реакций, которые не нужны для ответа: отправить письмо, начислить бонусы, обновить поиск, аналитику. Плюсы: издатель не знает потребителей, новых можно добавлять без его изменения, отказ потребителя не мешает издателю, брокер сглаживает пики. Цена:
- согласованность в конечном счёте;
- доставка обычно «хотя бы один раз» — обработка обязана быть идемпотентной;
- сложнее отлаживать и прослеживать (нужна трассировка через брокер);
- публикация события должна быть согласована с изменением данных — outbox.
Третий вариант — команда через очередь (асинхронный запрос с ответом позже): длительные задачи, например генерация отчёта.
REST или gRPC для синхронного: REST — для внешних клиентов и браузера, понятный и кэшируемый; gRPC — между сервисами: бинарный протокол, строгая схема, потоковая передача, HTTP/2, но хуже для браузера и отладки руками.
Что хотят услышать
- Критерий: нужен ли ответ немедленно.
- Плюсы событий для связанности и надёжности.
- Цена: итоговая согласованность, идемпотентность, outbox.
- REST против gRPC для синхронных вызовов — плюс.
Частые ошибки
- Делать синхронными все вызовы «для простоты».
- Использовать события там, где пользователю нужен результат сразу.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Какой объём данных передаётся и укладывается ли он в лимит одного сообщения брокера
- ✗На каком языке написан вызываемый сервис и есть ли для него клиент брокера
- ✓Нужен ли вызывающему ответ прямо сейчас, чтобы продолжить работу
- ✗Есть ли у команды опыт эксплуатации Kafka или другого брокера сообщений
Что спросят дальше
- Чем gRPC выигрывает у REST внутри периметра?
- Почему при событиях обработка обязана быть идемпотентной?
Разбор темы
- Проектирование API: REST, gRPC и события
Выбор стиля взаимодействия, семантика и идемпотентность HTTP, формат ошибок, курсорная пагинация против offset, версионирование и обратная совместимость, контрактное тестирование.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.