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

Такие ошибки опасны тем, что не всегда воспроизводятся вручную. Они часто появляются при reconnect, высокой нагрузке или временных сбоях сети.

Коротко: каждое событие должно иметь уникальный идентификатор и безопасную повторную обработку.

Почему возникает такая проблема

Причина может быть в нескольких активных подписках, повторном подключении клиента, retry очереди, отсутствии ack, запуске нескольких worker без блокировки или обработчике, который не проверяет, было ли событие уже применено.

Что проверить в первую очередь

  • есть ли уникальный id события
  • сколько подписчиков получает одно сообщение
  • как работает reconnect
  • есть ли retry в очереди
  • защищена ли запись в базе от дублей

Как я подхожу к задаче

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

  • собираю логи по одному событию
  • проверяю подписки и reconnect
  • смотрю очередь и retries
  • добавляю идемпотентную проверку
  • тестирую повторную доставку события

Что подготовить для быстрой диагностики

  • пример дублирующегося события
  • время появления дубля
  • тип realtime-технологии
  • доступ к логам и коду
  • описание ожидаемого результата

Сроки и аккуратность

Если дубль только на клиенте, исправление может быть быстрым. Если повтор влияет на базу или оплату, нужно добавить серверную защиту и миграцию уже созданных дублей.

Чего лучше не делать

Не пытайтесь просто отключить retries. Повторы нужны для надежности, но обработчик должен переносить их безопасно.

FAQ

Почему событие приходит дважды после reconnect?

Клиент может создать вторую подписку, не закрыв первую.

Очередь может доставить событие повторно?

Да, это нормальное поведение многих очередей при ошибках или таймаутах.

Что такое идемпотентность?

Это когда повторный запуск операции не меняет результат второй раз.

Можно ли исправить только frontend?

Если дубль уже записывается в базу, исправлять нужно на сервере.

Нужна похожая задача?

Напишите в Telegram @rabotator_support или оставьте заявку на сайте. Пришлите ссылку на проект, опишите проблему и укажите, какие доступы уже есть. Я посмотрю задачу, предложу безопасный план и скажу, с чего лучше начать.

Итог

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