At-most-once, at-least-once, exactly-once: три контракта доставки

Payment worker обрабатывает сообщение «списать $50» и падает до того, как успевает сообщить очереди о завершении. Очередь передоставляет. Клиент списан дважды. Это не баг в коде — это поведение по умолчанию каждой production-очереди в мире.

Три контракта

Каждая message queue предлагает delivery-контракт — гарантию о том, сколько раз сообщение дойдёт до consumer-а при сбоях.

At-most-once. Брокер отправляет сообщение один раз и никогда не ретраит. Если сеть роняет сообщение — оно потеряно. Дубликатов нет, но возможна потеря. Use case: debug-логи, некритичная телеметрия. Никогда — для денег, заказов или событий, потеря которых имеет бизнес-последствия.

At-least-once. Брокер ретраит, пока consumer не отправит явный ack. Если ack потерян — брокер передоставляет. Сообщение доходит минимум один раз, но возможно и больше. At-least-once — дефолт в SQS, RabbitMQ (with ack) и Kafka с дефолтными настройками.

Exactly-once. Каждое сообщение обрабатывается ровно один раз независимо от retry. Это то, что нужно. Проблема: чистая exactly-once delivery поверх ненадёжной сети математически невозможна — Two Generals’ Problem доказывает, что две стороны поверх ненадёжного канала никогда не могут быть уверены, что обе знают одно и то же. Нельзя гарантировать, что обе стороны знают: сообщение доставлено ровно один раз.

Что можно достичь — exactly-once processing: side effect consumer-а (списание карты, отправка email, обновление строки) происходит ровно один раз, даже если брокер доставит сообщение более чем один раз. Трюк — идемпотентный consumer.

Почему at-least-once — безопасный дефолт

At-most-once принимает потери. Для платёжной системы потерянное «списать клиента» — пропущенная транзакция, недопустимо. At-least-once принимает дубликаты. Дублирующее «списать клиента» — двойное списание, тоже плохо, но исправимо на стороне consumer. Exactly-once delivery недостижима без дорогой координации.

Конвергенция индустрии: at-least-once delivery + идемпотентный consumer. Consumer проверяет «обработал ли я этот msg ID уже?» перед действием. Дубликаты игнорируются. Очередь может ретраить без вреда.