Что такое паттерн Transactional Outbox?

Смотри, объясню тебе про этот Transactional Outbox, а то народ часто голову ломает, как события в системе гарантированно доставлять. Суть в том, чтобы не оказаться в ситуации "данные есть, а событие — хуй там".

Представь, у тебя типичная операция: сохранил заказ в базу и тут же должен кинуть событие OrderCreated в Кафку. И всё бы ничего, но эти две хуйни — не атомарны. Может случиться пиздец: заказ в базу упал, а перед самым выстрелом в брокер приложение легло. И всё, система в рассинхроне — заказ есть, а другие сервисы ни хуя об этом не знают. Классика жанра.

А выход-то простой, как три копейки. Нужно использовать саму базу данных как буфер для событий. Это и есть Outbox.

Как это работает, если по-человечьи:

1. Пишем всё за один присест. В рамках одной ебанной транзакции ты сохраняешь и свои бизнес-данные (тот же заказ), и событие об этом в специальную таблицу outbox. Это ключевой момент — либо всё сохранится, либо нихуя. База гарантирует.
2. Фиксируем транзакцию. Всё, теперь и заказ, и запись о событии лежат в базе. Можно выдохнуть.
3. Запускаем "мусорщика". Отдельный, долбоёбский, фоновый процесс (outbox processor) тупо периодически долбит эту таблицу: "Э, есть чо неотправленного?".
4. Отправляем и метим. Находит такие записи — пиздует их в настоящий брокер (Kafka/RabbitMQ). После успешной отправки помечает запись как обработанную (ставит флажок или вообще удаляет). Если при отправке сбой — попробует ещё раз, записи-то никуда не делись.

Вот тебе кусок кода на C#, чтобы стало совсем понятно:

// Это наша моделька для сообщения в outbox-таблице
public class OutboxMessage
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public string Type { get; set; } // Например, "OrderPlaced"
    public string Payload { get; set; } // Событие, сериализованное в JSON
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
    public DateTime? ProcessedAt { get; set; } // Когда отправили
}

// А вот как этим пользоваться в сервисе
public async Task PlaceOrder(Order order, AppDbContext context)
{
    // Начинаем одну большую транзакцию
    using var transaction = await context.Database.BeginTransactionAsync();
    try
    {
        // 1. Сохраняем бизнес-объект (заказ)
        context.Orders.Add(order);
        await context.SaveChangesAsync();

        // 2. Сразу в той же транзакции пишем событие в outbox
        var outboxMessage = new OutboxMessage
        {
            Type = "OrderPlaced",
            Payload = JsonSerializer.Serialize(new OrderPlacedEvent(order.Id))
        };
        context.OutboxMessages.Add(outboxMessage);

        // Сохраняем и событие тоже
        await context.SaveChangesAsync();
        // Фиксируем! Теперь и заказ, и событие в базе намертво.
        await transaction.CommitAsync();
    }
    catch
    {
        await transaction.RollbackAsync();
        throw; // Если что-то пошло не так — откатываем ВСЁ.
    }
}

Что хорошего?

• Ничего не потеряется. Главный плюс. Даже если сервер нахуй сгорит сразу после коммита, событие останется в базе и будет отправлено, когда поднимемся.
• Простота в голове. Бизнес-логика не парится о доставке, она просто пишет в свою же базу.
• Согласованность. Нет этого дурацкого состояния "данные есть, а события нет".

Но и подводные камни есть, куда без них:

• Лишняя движуха. Таблица, процессор, мониторинг — всё это надо писать и поддерживать.
• Не мгновенно. Событие уйдёт не в ту же миллисекунду, а когда процессор проснётся и проверит таблицу. Обычно задержка небольшая, но она есть.
• Возможны дубли. Процессор может отправить сообщение, пометить его, а потом упасть до подтверждения. При перезапуске отправит ещё раз. Поэтому потребители событий должны быть идемпотентными — чтобы обработка одного и того же события дважды не сломала логику.

Короче, паттерн рабочий, железобетонный. Если тебе критична гарантированная доставка и ты не готов мириться с потерей событий — это твой выбор. Просто помни про компромиссы.