Как микросервисы общаются между собой: через REST или Kafka

Что проверяют

Понимаете ли вы, что выбор делается под конкретное взаимодействие: нужен ли ответ прямо сейчас и что будет, если получатель лежит. Следом обычно спрашивают про гарантии доставки и про то, как не потерять событие между записью в базу и отправкой в Kafka.

Как отвечать

Разведите два стиля:

• синхронный запрос (REST, gRPC): вызывающий ждёт ответа, сервисы связаны по времени. Подходит, когда результат нужен для ответа пользователю: проверить остаток, получить цену. В Spring это RestClient или WebClient, для внутреннего трафика со строгим контрактом часто берут gRPC;
• асинхронные события (Kafka): сервис публикует факт «заказ создан», подписчики обрабатывают его в своём темпе. Отправитель не знает получателей, а получатель может лежать час и потом дочитать с сохранённого offset. Сообщения с одним ключом попадают в одну партицию, порядок гарантирован только внутри неё;
• цена синхронности: цепочка складывает латентность и перемножает доступность. Пять сервисов по 99,9% дают около 99,5% на всю цепочку, поэтому нужны таймауты и circuit breaker;
• цена асинхронности: eventual consistency, дубли и сложная отладка. Типичная настройка даёт at-least-once, значит, консьюмер обязан быть идемпотентным, а для сквозной трассировки нужен OpenTelemetry;
• связка с базой: запись в БД и публикация в Kafka это две операции, между ними событие теряется. Решение: transactional outbox, событие пишется в таблицу в той же транзакции и отправляется через Debezium или отдельный поллер.

Зрелый ответ: запросы с немедленным ответом идут синхронно, а уведомления о случившемся рассылаются событиями.

Где спотыкаются

Называют Kafka «быстрее REST». Kafka даёт пропускную способность и развязку, а задержка одного сообщения от продюсера до консьюмера обычно выше, чем у прямого HTTP-вызова.

Строят через Kafka синхронный запрос-ответ: отправили событие и блокируют поток в ожидании ответа из другого топика. Получается сложность асинхронности плюс хрупкость синхронности.

Не думают о дублях. Событие придёт повторно после ребаланса консьюмер-группы, и если обработчик списывает деньги без проверки идентификатора, списание будет двойным.