Повторная техническая отправка и новое обращение одного человека — разные события. Дубли нужно определять по контексту, сохраняя возможность проверить решение.
Различайте попытку и задачу
Повтор одного запроса может возникнуть из-за двойного нажатия или потери подтверждения. Для такого случая полезен идентификатор попытки, по которому система возвращает прежний результат. Новый запрос того же человека через неделю может относиться к другой работе.
Условный пример: посетитель дважды нажал отправку одной формы — должна сохраниться одна логическая заявка. Затем он обратился за другой услугой — это самостоятельная задача. Совпадение контакта не является достаточной причиной удалить запись.
Фиксируйте основания объединения
Сравнивайте идентификатор, время, содержание и источник в рамках согласованных правил. Не объединяйте автоматически однофамильцев или все обращения с общего телефона организации. При сомнении помечайте возможный дубль для проверки человеком.
История должна показывать, какие записи связаны и почему. Сотруднику важно видеть полный контекст, а не исчезнувшие сведения. Изменение правил влияет на бизнес-логику и требует согласования владельца; техническая удобность не заменяет такого решения.
Проверьте крайние ситуации
В тестах нужны двойное нажатие, сетевой повтор, возвращение позже и новая задача с тем же контактом. Проверьте также восстановление после сбоя. Безопасность повторов особенно важна, когда действие отправляет уведомления или создаёт внешние записи.
Для отчётности отделяйте число попыток от уникальных логических обращений. Не скрывайте возможные ошибки объединения за красивым итогом. Критерий качества — сохранение смысла клиентского запроса и управляемость повторной обработки, а не минимальное число строк в журнале.
- Одна попытка или новая задача?
- Проверяемое основание связи.
- Сохранённая история.
- Ручная проверка неопределённых случаев.