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