📨 Очереди и события

Короткий ответ Transactional Outbox решает проблему dual write, записывая событие в отдельную таблицу outbox в той же транзакции БД, что и бизнес-изменение, а отдельный процесс затем читает outbox и публикует события в очередь. Как это работает подробнее Бизнес-операция и вставка строки в outbox происходят в одной локальной транзакции БД атомарно; relay-процесс (poller или CDC, например Debezium) читает новые строки outbox и публикует их в брокер. Пример кода Что использовать на практике Практика. Избавляет от ситуации, когда БД-транзакция закоммитилась, а публикация в очередь не прошла; relay обеспечивает at-least-once публикацию, и consumer всё равно должен быть идемпотентным. Подводные камни Риск. Публиковать событие до коммита транзакции БД (если транзакция откатится — событие о несуществующем изменении уже ушло); публиковать после коммита отдельным не атомарным вызовом без outbox.

Читать полностьюevent-driven

Короткий ответ При раздельной записи в БД и публикации в очередь без общей транзакции возможна рассинхронизация: БД обновилась, а сообщение не отправлено (или наоборот), поскольку это два независимых ресурса без атомарной гарантии между ними. Как это работает подробнее Последовательность «commit в БД, затем publish в очередь» оставляет окно между операциями, где процесс может упасть после коммита, до publish — сообщение не отправится, а данные уже изменены. Пример кода Что использовать на практике Практика. Двухфазные транзакции (XA) между БД и большинством брокеров почти не используются из-за сложности и блокировок; практическое решение — Transactional Outbox либо change data capture. Подводные камни Риск. Оборачивать публикацию в try/except и повторять при любой ошибке без идемпотентности на стороне consumer — снижает потерю, но может привести к дублям; игнорировать проблему вовсе.

Читать полностьюevent-driven

Короткий ответ HTTP-вызов — синхронный, вызывающий ждёт ответ немедленно; отправка в очередь — асинхронная, вызывающий не ждёт обработки, а получает лишь подтверждение постановки сообщения. Как это работает подробнее HTTP создаёт прямую временную связанность (сервис-получатель должен быть доступен прямо сейчас); очередь развязывает отправителя и обработчика во времени — сообщение дождётся, пока consumer освободится. Пример кода Что использовать на практике Практика. Синхронный вызов — для операций, где нужен немедленный результат (проверка остатка перед покупкой); очередь — для фоновых задач (отправка email, пересчёт аналитики), где задержка в секунды/минуты допустима. Подводные камни Риск. Использовать синхронный вызов для долгих операций (блокирует клиента и поток); использовать очередь там, где нужен немедленный ответ пользователю.

Читать полностьюevent-driven

Короткий ответ Синхронный вызов выбирают, когда вызывающей стороне нужен немедленный результат для продолжения обработки; асинхронное сообщение — когда результат можно получить с задержкой, отправитель не должен блокироваться на доступности получателя, или нужно уведомить несколько независимых подписчиков. Как это работает подробнее Синхронный вызов создаёт временную связанность — оба сервиса должны быть доступны одновременно; сообщение развязывает это, но отправитель не может немедленно узнать результат обработки. Пример кода Что использовать на практике Практика. Критерии выбора: нужен ли результат прямо сейчас для ответа пользователю; сколько получателей должны знать о событии; насколько критична доступность получателя прямо в момент отправки. Подводные камни Риск. Делать все интеграции синхронными «для простоты», создавая цепочку хрупких зависимостей; делать критичную для пользователя операцию полностью асинхронной без способа дождаться результата.

Читать полностьюevent-driven

Короткий ответ Идемпотентный consumer хранит признак уже обработанных сообщений (по уникальному ключу) и, получив дубликат, пропускает повторную обработку, возвращая тот же эффект, что и при первой обработке. Как это работает подробнее При получении сообщения consumer сначала проверяет, есть ли запись об обработке message_id; если есть — подтверждает получение без повторного эффекта; если нет — выполняет обработку и атомарно фиксирует факт обработки вместе с результатом. Пример кода Что использовать на практике Практика. Ключ идемпотентности должен быть стабильным и уникальным для бизнес-операции (order_id + event_type), а не техническим delivery tag брокера, который меняется при каждой redelivery. Подводные камни Риск. Хранить «обработано» только в памяти процесса (при перезапуске теряется); проверять и фиксировать факт обработки в двух разных нетранзакционных шагах, оставляя окно гонки при параллельной обработке дублей.

Читать полностьюconsumer

Короткий ответ DLQ — отдельная очередь, куда сообщение перемещается после превышения числа неудачных попыток обработки, чтобы не блокировать обработку остальных сообщений и дать возможность разобрать проблемное сообщение отдельно. Как это работает подробнее Consumer при повторной ошибке обработки (после N попыток или определённого вида ошибки) явно отправляет сообщение в DLQ вместо бесконечного retry или потери; основная очередь продолжает обрабатывать следующие сообщения. Пример кода Что использовать на практике Практика. Сообщения в DLQ должны сопровождаться метаданными об ошибке; дальше с DLQ работают через мониторинг (алерт при появлении новых сообщений), ручной разбор либо автоматический replay после исправления причины. Подводные камни Риск. Не мониторить DLQ вообще — сообщения тихо скапливаются; отправлять в DLQ сообщения с временными ошибками без достаточного числа retry перед этим.

Читать полностьюdead-letter-queue

Короткий ответ Kafka подходит, когда нужен упорядоченный, воспроизводимый и долгоживущий журнал событий с возможностью перечитывания и масштабированием через партиционирование по ключу; RabbitMQ подходит для сценариев «задача-очередь» с гибкой маршрутизацией, где порядок важен в основном в пределах одной очереди. Как это работает подробнее Kafka гарантирует порядок только в пределах одной партиции, поэтому для сохранения порядка связанных событий нужно направлять их в одну партицию через ключ; RabbitMQ гарантирует порядок в пределах одной очереди при единственном consumer'е, а при нескольких конкурирующих consumer'ах порядок обработки не гарантирован. Kafka даёт долгое хранение истории, replay и масштабируемость через партиции, но требует сложной операционной модели и явного мышления о партиционировании для гарантий порядка; RabbitMQ проще в небольших сценариях маршрутизации задач, но слабее подходит для большого объёма событий с долгим хранением и повторным чтением истории. Критерий выбора — нужен ли replay/

Читать полностьюevent-driven

Короткий ответ At-most-once — сообщение может быть потеряно, но не дублировано; at-least-once — гарантированно доставляется, но может продублироваться; exactly-once на практике достигается не самим брокером, а комбинацией at-least-once доставки и идемпотентной обработки на стороне consumer'а. Как это работает подробнее At-most-once — consumer подтверждает (ack) до обработки, и при сбое между ack и обработкой сообщение теряется; at-least-once — ack после успешной обработки, и при сбое до ack брокер повторно доставит сообщение. Пример кода Что использовать на практике Практика. Большинство систем (Kafka, RabbitMQ с manual ack) по умолчанию работают в режиме at-least-once, и ответственность за отсутствие побочных эффектов от дублей перекладывается на consumer. Подводные камни Риск. Путать «exactly-once delivery» брокера с «exactly-once processing» — consumer может обработать сообщение дважды из-за собственного сбоя; считать, что включение exactly-once semantics в Kafka решает проблему без идемпотентных внешних s

Читать полностьюevent-driven

Короткий ответ Producer — часть системы, которая создаёт и отправляет сообщения в очередь; consumer — часть, которая читает сообщения из очереди и обрабатывает их; это разные роли, часто в разных сервисах. Как это работает подробнее Producer не знает, кто и когда обработает сообщение; consumer подписывается на очередь/топик и обрабатывает сообщения в своём темпе. Пример кода Что использовать на практике Практика. Один producer может иметь несколько consumer'ов для масштабирования обработки; в Kafka несколько consumer'ов в одной consumer group делят партиции между собой. Подводные камни Риск. Путать широковещательную доставку (каждый consumer получает копию, fanout) с разделением нагрузки (конкурирующие consumer'ы делят сообщения).

Читать полностьюconsumer