Как выбрать подход взаимодействия между микросервисами: синхронный или асинхронный
Что проверяют
Есть ли у вас критерии выбора и понимаете ли вы, что синхронный вызов связывает сервисы по доступности.
Как отвечать
Основной вопрос один: нужен ли вызывающему ответ, чтобы продолжить прямо сейчас.
Синхронно (HTTP или gRPC), когда:
- результат нужен для формирования ответа пользователю: проверить лимит, получить цену, подтянуть профиль;
- операция короткая и предсказуемая;
- нужен строгий контракт и немедленная ошибка при неверных данных.
Асинхронно (через брокер), когда:
- произошло событие, и о нём должны узнать другие, а отправителю всё равно кто и когда;
- получателей несколько или их состав меняется: добавить потребителя можно без правки отправителя;
- работа долгая: отправка писем, генерация документа, пересчёт;
- нагрузка неравномерная, и очередь сглаживает пик;
- получатель может быть временно недоступен.
Главный аргумент, который надо назвать словами: синхронный вызов связывает сервисы по доступности. Цепочка из четырёх вызовов перемножает их надёжности, и падение самого дальнего роняет весь сценарий. Асинхронный обмен эту связь разрывает, но платит согласованностью в конечном счёте: данные обновятся не мгновенно, и это надо заложить в интерфейс.
Практический ответ почти всегда гибридный: команды и запросы синхронно, факты о произошедшем асинхронно событиями. Часто добавляют локальные копии справочных данных, чтобы не ходить за ними синхронно на каждый запрос.
Что обязательно при любом выборе: таймауты меньше, чем у вызывающего, ограниченные повторы с экспоненциальной задержкой и разбросом, предохранитель, идемпотентность обработчиков, сквозная трассировка. Отдельно для асинхронного пути: транзакционный ящик исходящих, иначе запись в базу и публикация события однажды разойдутся.
Где спотыкаются
Строят длинные цепочки синхронных вызовов.
Ждут ответа через очередь, превращая асинхронность в неудобный запрос.
Не делают обработчики идемпотентными.
Не показывают пользователю, что данные обновятся с задержкой.