Какие техники позволяют избежать повторной обработки событий при работе с внешними сервисами?

1. Откуда возникают дубли событий

Определение.
Дублирование события — это ситуация, когда внешняя система отправляет одно и то же событие несколько раз (по сети, ретраям, ошибкам доставки).

Причины:

1. Сервис повторно отправляет webhook при задержке ответа.

2. Сеть может прервать соединение после обработки.

3. Очередь может повторно доставить сообщение.

4. Балансировщик может сделать повторный запрос.

Поэтому система должна быть устойчивой к многократной доставке одного и того же сообщения.

2. Основные техники предотвращения повторной обработки

2.1. Использование внешнего уникального event_id

Лучший случай:

1. Сервис присылает поле event_id.

2. Мы создаём таблицу processed_events(event_id PRIMARY KEY).

3. При обработке пытаемся вставить event_id.

4. Если вставка успешна — событие новое.
   Если турнится ошибка «unique violation» — событие дубликат.

2.2. Искусственный ключ идемпотентности

Если event_id нет — создаём собственный ключ:

• Хеш от содержимого события.

• Комбинация бизнес-полей (order_id, event_type, amount).

Храним ключ в БД или Redis.

2.3. Redis + atomics (например, SETNX)

Механизм Redis:

1. Попытка выполнить SET key value NX EX ttl.

2. Если ключ установлен — событие новое.

3. Если нет — дубликат, прекращаем обработку.

Python

if redis.set(key, "1", ex=86400, nx=True):
    process_event(event)

Преимущества:

• Очень быстро.

• Поддерживает TTL, не копится мусор.

• Гарантирует атомарность операции.

2.4. Уникальный индекс в базе данных

Можно сделать таблицу:

idempotency(event_id TEXT UNIQUE, processed_at TIMESTAMP)

Логика:

1. Пытаемся вставить event_id.

2. В случае ошибки уникальности — событие уже обработано.

Это надёжнее Redis, но медленнее.

2.5. Очереди и семантика «ровно один раз»

Некоторые очереди (Kafka, RabbitMQ + idempotent consumer) поддерживают:

• Хранение offset.

• Ручное подтверждение обработки.

• Гарантии порядка и повторной доставки.

Чтобы избежать повторной обработки:

1. Храните offset в устойчивой БД.

2. Обрабатывайте событие только, если offset > last_processed_offset.

2.6. Логика идемпотентности на уровне бизнес-операций

Иногда само действие можно сделать идемпотентным:

Примеры:

1. «Установить баланс на 100» — операция идемпотентна.
   «Добавить +100» — нет.

2. «Обновить статус заказа на PAID» — идемпотентно.
   «Создать новую запись транзакции» — нет.

Идея: превратить действие в операцию «set», а не «increment».

3. Как объединять техники

На практике обычно объединяют:

1. Хеш/ID события → таблица/Redis → проверка на дубликат.

2. Асинхронная очередь → обработчик с фиксирующим offset.

3. Идемпотентная бизнес-логика.

Комбинация даёт максимальную надёжность.

4. Вывод

Чтобы избежать повторной обработки событий, нужно либо иметь уникальный внешний идентификатор, либо создавать его самостоятельно. Далее этот идентификатор фиксируется в БД или Redis, а попытки повторной обработки блокируются. При более сложных сценариях используются очереди и контроль offset. Идеальный вариант — когда и операция, и обработка построены как идемпотентные.