Как повторная доставка сообщения создаёт дубли в аналитике, почему она бывает допустимой и что нужно согласовать до подсчёта заказов.
Когда один заказ выглядит как два
Покупатель оформил один заказ, а в отчёте оказалось два одинаковых события оплаты. Это не всегда две покупки. Система могла отправить сведения повторно после временного сбоя связи: подтверждение не дошло, и отправитель решил, что сообщение следует доставить ещё раз. Получатель увидел две копии одного события.
Такая ситуация особенно важна там, где приложения обмениваются сообщениями через очередь. Очередь помогает не потерять событие при временной недоступности получателя. Плата за надёжность в некоторых режимах — возможность повторной доставки, с которой обработчик должен справляться осознанно.
Почему «доставлено» не означает «один раз»
Официальная документация Amazon SQS прямо описывает для стандартных очередей доставку как минимум один раз: копии сообщения могут прийти снова. Это свойство конкретного режима очереди, а не доказательство, что любой сервис неизбежно дублирует все сообщения.
Представьте курьера, который передал конверт, но не получил расписку из-за пропавшей связи. Он приносит его повторно. Получатель должен отличить уже полученный конверт от нового, даже если оба пришли сегодня. По одному лишь времени прихода это сделать надёжно не получится.
Условный расчёт для отчёта
Допустим, в магазин поступило сто реальных заказов. Сообщение об одном из них пришло дважды. Если считать каждую доставку отдельным заказом, отчёт покажет сто один. Разница мала, но для денег, остатков или вознаграждений даже одна ошибочная операция может быть существенной. Пример условный: реальная частота повторов зависит от системы.
Если у каждого события есть устойчивый идентификатор, можно распознать повторную доставку. Но одинаковая сумма и одинаковый клиент не доказывают дубль: человек вправе дважды купить один и тот же товар. Правило идентификации нужно согласовать с тем, кто создаёт событие, а не угадывать по похожим строкам.
Что значит безопасно обработать повтор
Полезное свойство обработки — повтор одного и того же события не должен повторно менять итог. Если событие уже учтено, новая доставка должна быть распознана, а не добавлена как ещё одна покупка. AWS рекомендует учитывать возможные дубли в приложениях, работающих со стандартными очередями.
Это не означает, что все повторные события надо выбросить без анализа. Сначала надо убедиться в стабильности идентификатора, определить срок его хранения и понять, что считать одной бизнес-операцией. Повторная доставка, исправление заказа и новая покупка — разные случаи.
Как проверить свою цепочку
Спросите у команды источника, может ли сообщение быть доставлено больше одного раза и как формируется его идентификатор. Затем проверьте, что делает приёмник при повторе, и сравните число уникальных операций в источнике с итогом аналитики. Отдельно разберите задержки и ошибки подтверждения.
Тема связана с повторной загрузкой данных, но здесь вопрос возникает ещё до полного перезапуска потока — на уровне отдельного события. Передавать изменения вместо полной копии помогает подход CDC; он тоже требует ясного правила обработки повторов. Основы построения таких потоков входят в направление Data Engineer.
Где заканчивается ответственность очереди
Очередь доставляет сообщения по своим правилам, но не знает, какой результат бизнес считает правильным. Для неё две доставки одного сообщения могут быть допустимым способом сохранить надёжность. Для отдела продаж две записи об одной оплате — ошибка. Поэтому граница между транспортом и аналитическим учётом должна быть явно описана.
Особенно важно проверить последствия при частичном сбое: получатель уже сохранил операцию, а подтверждение отправить не успел. После восстановления он увидит сообщение снова. Если правило повторной обработки заранее не согласовано, исправлять отчёт придётся вручную.
Курс по теме
Подходящая программа для дальнейшего изучения темы: Data Engineer для начинающих.
