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