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