Что хотят услышать интервьюеры:

Брокер сообщений помогает развязать сервисы и повысить надежность обмена данными. Но это не замена классической ACID-транзакции: при распределенном обмене обычно приходится строить согласованность через eventual consistency, идемпотентность и ретраи. Важно понимать, где такой подход дает выигрыш, а где усложняет систему.

Определение:

Брокер сообщений — это промежуточный компонент, через который один сервис публикует событие или команду, а другой забирает и обрабатывает ее асинхронно. Для реализации транзакций в такой архитектуре брокер используют не для «одной общей транзакции», а для надежной передачи факта изменения между частями системы. Это повышает отказоустойчивость и масштабируемость, но усложняет гарантию строгой согласованности.

Пример использования:

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

// Псевдокод: заказ сохраняется в БД, затем публикуется событие в брокер
public async Task CreateOrderAsync(Order order)
{
    using var transaction = await db.Database.BeginTransactionAsync();

    db.Orders.Add(order);
    await db.SaveChangesAsync();

    await messageBroker.PublishAsync(new OrderCreated
    {
        OrderId = order.Id,
        Amount = order.Total
    });

    await transaction.CommitAsync();
}

На практике часто используют паттерн Outbox, чтобы запись в БД и публикация сообщения не расходились.

Пояснение кода:

Код показывает типичный сценарий: сначала данные заказа сохраняются в базе, затем в брокер отправляется событие о создании заказа. Если бы публикация была сделана совсем отдельно, возможна ситуация, когда заказ уже сохранен, а сообщение не ушло из-за сбоя. Чтобы уменьшить такой риск, часто применяют Outbox: событие сначала сохраняют в ту же БД, а отдельный фоновой процесс позже публикует его в брокер. Так достигается надежность без распределенной транзакции между БД и брокером.

Ключевые моменты:

Брокер сообщений хорошо подходит для асинхронной координации между сервисами.
Главный плюс — слабая связность, масштабируемость и устойчивость к временным сбоям.
Главный минус — сложнее обеспечить строгую атомарность между БД и сообщением.
Обычно вместо «настоящей распределенной транзакции» используют eventual consistency, ретраи и идемпотентные обработчики.
Для надежной доставки часто применяют паттерн Outbox.
Если нужна жесткая ACID-согласованность в одном домене, брокер не заменяет обычную транзакцию в БД.

В чем преимущества и недостатки использования брокера сообщений для реализации транзакций?