Как не создавать дубли при повторной передаче заявки

Разберите причину повторной отправки

Человек нажимает кнопку дважды, браузер повторяет действие после обрыва связи, очередь повторяет запрос к CRM. Во всех случаях может возникнуть один и тот же побочный эффект: две записи вместо одной. Но два обращения одного человека в разные дни могут быть самостоятельными задачами. Защита должна различать повтор операции и похожие данные клиента.

Начните с определения логической операции. Для формы это может быть одно подтверждённое отправление конкретного черновика. Для интеграции — передача события с устойчивым идентификатором. Телефон или почта не подходят как универсальный ключ: один клиент вправе создать несколько разных запросов. Схема дедупликации по контактам решает другую задачу.

Опишите контракт ключа

Срок хранения выбирают по реальному окну повторов и возможностям системы. Не копируйте значение из чужого API без анализа. Например, документация Stripe описывает собственные правила сохранения результата и проверки параметров. Это иллюстрация технического контракта, а не рекомендация платёжного сервиса для российского проекта.

Сохраняйте результат согласованно

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

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

Учитывайте потерю ответа после успеха

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

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

Проведите ключ через интеграцию

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

Для фоновой доставки храните связь между обращением и внешним объектом. Повтор задания должен проверять фактический результат в рамках контракта. Не делайте вывод, что наличие одного сообщения в очереди гарантирует один внешний эффект. Порядок повторов и разбор ошибок рассматриваются в статье о фоновых задачах.

Учебный набор проверок

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

Отдельно создайте две разные заявки с одним телефоном: обе должны сохраниться, если это допустимо процессом. Такой тест защищает от чрезмерного объединения. В журнале используйте идентификаторы и минимальные диагностические сведения, избегая ненужного копирования персональных данных.

Когда защита считается завершённой

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

Как отличить безопасный повтор от нового намерения клиента

Идемпотентный ключ относится к логической операции, а не навсегда к человеку. В учебной форме повтор после потери ответа использует прежний ключ и прежнее содержимое. Новая заявка с другой задачей получает новый ключ, даже если телефон совпадает.

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