События, повторы и дубликаты

Считайте повтор нормальным случаем

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

Отделите приём от обработки

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

Используйте ключ события

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

event_id: evt-00042
record_id: lead-001
operation: updated

Это пример структуры, а не адрес или формат конкретного API. Для своего сервиса используйте опубликованный контракт.

Ограничьте повторы

Повторяйте временные ошибки с растущей задержкой и небольшим случайным разбросом. Учитывайте Retry-After, если сервер его передаёт. После установленного предела отправляйте событие в очередь разбора, сохраняя причину и число попыток.

Ошибку формата данных обычно нужно исправить, а не отправлять без изменений бесконечно. Не записывайте токены, пароли и полные персональные данные в журнал повторов.