Когда для взаимодействия микросервисов стоит выбрать брокер сообщений вместо HTTP?

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

Когда брокер предпочтительнее

• Операция длительная или ресурсоёмкая (генерация отчёта, обработка изображения).
• Нужна слабая связанность: отправитель не знает о получателях.
• Требуется устойчивость к временной недоступности сервиса-получателя.
• Одно событие должно обрабатываться несколькими сервисами (fan-out).
• Нужна буферизация при пиковых нагрузках и повторная обработка при ошибках.

Пример на Node.js с RabbitMQ

// publisher.js
const amqp = require('amqplib');

async function publishOrder(order) {
  const conn = await amqp.connect('amqp://localhost');
  const ch = await conn.createChannel();
  await ch.assertQueue('orders');
  ch.sendToQueue('orders', Buffer.from(JSON.stringify(order)));
  console.log('Order sent:', order.id);
}

publishOrder({ id: 42, total: 199 });

Издатель просто кладёт сообщение в очередь и не ждёт, пока его обработают. Если сервис-потребитель упал, сообщение останется в очереди и будет обработано после восстановления.

Когда лучше остаться на HTTP

• Нужен немедленный ответ пользователю (авторизация, чтение данных).
• Простая синхронная бизнес-логика без побочных эффектов.
• Низкая нагрузка и отсутствие требований к отказоустойчивости.

На практике часто комбинируют оба подхода: HTTP для запросов пользователя и брокер для внутренних событий и фоновых задач.

Итог: брокер сообщений стоит применять там, где важны асинхронность, слабая связанность и устойчивость к сбоям, а HTTP оставить для синхронных операций, требующих немедленного ответа.