Канал уведомлений: сравнение, выбор и резервный канал

Прямой ответ

Канал доставки определяет стоимость, своевременность и вероятность получения уведомления. Выбор канала привязывается к типу события, а не задаётся единым для всех сообщений.

Уведомление внутри приложения не требует внешних зависимостей, но доставляется только при открытии приложения, поэтому не подходит для срочных сообщений.

Email покрывает большинство случаев при низкой стоимости, а доставляемость зависит от аутентификации домена и репутации. Web push доставляется быстрее, но требует подписки и работает только при запущенном браузере; о настройке — в статье про browser push.

SMS используется для сообщений, где получение критично независимо от состояния приложений. Стоимость канала в разы выше остальных; о расчёте — в статье про SMS-уведомления.

Выбор канала выполняется по двум признакам: критичность события и доступность канала для конкретного пользователя.

SELECT channel FROM notification_preferences
WHERE user_id = $1 AND event_type = $2 AND is_enabled
ORDER BY CASE channel
    WHEN 'in_app' THEN 1 WHEN 'email' THEN 2
    WHEN 'push' THEN 3 WHEN 'sms' THEN 4 END;

Резервирование канала и поведение при отказе

Отказ канала не означает, что уведомление не требуется. Резервирование определяет, что происходит при недоставке основным каналом.

Последовательная деградация. Уведомление отправляется основным каналом, а при недоставке в течение заданного интервала — резервным. Интервал определяется критичностью события.

Параллельная отправка. Критичное сообщение отправляется одновременно несколькими каналами, поскольку ожидание результата основного канала занимает время.

Отсутствие резервирования. Сообщение отправляется одним каналом, а недоставка фиксируется без повторной попытки другим каналом.

Выбор схемы определяется стоимостью и критичностью. Параллельная отправка удваивает расходы, поэтому применяется к событиям, где пропуск недопустим.

Практическое следствие: резервный канал указывается в настройке типа события, а не определяется в момент отказа, поскольку решение о допустимых каналах принимается заранее.

Отдельный вопрос — доступность канала для пользователя. У пользователя может отсутствовать подпись на push либо действующий адрес почты, поэтому фактический набор каналов определяется по данным пользователя, а не по перечню в системе.

Отсутствие канала не означает отсутствие уведомления: сообщение сохраняется в истории внутри приложения и отображается при следующем входе. О разделении записи и отправки — в статье про архитектуру уведомлений.

Деградация при отказе внешнего провайдера требует ограничения повторов, иначе накопление неотправленных сообщений приводит к лавине после восстановления; о повторах — в статье про очередь уведомлений.

Практика: выбор и настройка каналов

1. Привязывайте канал к типу события. Критичность события определяет допустимые каналы, а не единая настройка для всех сообщений.

2. Определяйте доступность канала по данным пользователя. Отсутствие адреса либо подписки исключает канал из набора для конкретного пользователя.

3. Задавайте резервный канал в настройке типа события. Решение о допустимых каналах принимается заранее, а не в момент отказа.

4. Ограничивайте параллельную отправку критичными событиями. Отправка всеми каналами удваивает расходы без пользы для некритичных сообщений.

5. Сохраняйте уведомление в истории приложения. Недоставка внешним каналом не означает потерю сообщения.

6. Измеряйте долю доставки по каждому каналу. Снижение доли указывает на проблему с каналом, а не с логикой отправки.

7. Учитывайте предпочтения пользователя. Канал, отключённый пользователем, исключается из набора, кроме обязательных сообщений.

Рекомендации:

1. Не дублируйте одно сообщение всеми каналами по умолчанию. Пользователь получает несколько уведомлений об одном событии, что воспринимается как навязчивость.
2. Различайте недоставку и отказ. Недоставка по временной причине требует повтора тем же каналом, а не немедленного перехода к резервному.
3. Учитывайте стоимость при выборе резервного канала. SMS как резервный канал для массовой рассылки приводит к непропорциональным расходам.
4. Мониторьте время до доставки по каналам. Различие времени между каналами влияет на выбор интервала ожидания перед деградацией.
5. Документируйте соответствие событий и каналов. Перечень фиксируется, поскольку добавление события требует выбора каналов и резервирования.

Практический сценарий: критичное уведомление не дошло из-за отзыва подписки на push

Контекст: пользователь не получил уведомление о подозрительном входе в учётную запись.

1. Диагностика. Уведомление отправлено каналом web push и возвращено как недоставленное. Подписка оказалась недействительной после очистки данных браузера. Резервный канал для типа события не был задан.
2. Причина. Тип события «безопасность» настроен на единственный канал без резервирования. Отзыв подписки сделал канал недоступным, а сообщение не было отправлено другим способом.
3. Действия. (а) Добавили резервный канал email для событий безопасности с интервалом деградации пять минут; (б) включили параллельную отправку для событий безопасности, поскольку ожидание результата push занимает время; (в) добавили сохранение уведомления в истории приложения независимо от результата внешней доставки; (г) внедрили метрику доли недоставленных уведомлений по типам событий и каналам; (д) проверили наличие действующего адреса либо подписки при входе и запросили недостающие данные.
4. Результат. События безопасности доставляются несколькими каналами, а недоставка одним каналом не приводит к пропуску уведомления.

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

FAQ

Какой канал выбрать по умолчанию? Email как сочетание низкой стоимости и приемлемой своевременности. Уведомление внутри приложения дополняет его без внешних зависимостей.

Когда оправдан SMS? Для сообщений, где получение критично независимо от состояния приложений: коды подтверждения и уведомления о безопасности.

Что делать при отказе основного канала? Отправить резервным каналом по истечении интервала ожидания либо параллельно для критичных событий.

Нужно ли отправлять уведомление всеми каналами? Нет, кроме критичных событий. Дублирование воспринимается как навязчивость и увеличивает расходы.

Источники: MDN Push API, RFC 5321 (SMTP), Twilio SMS docs — ссылки в шапке.