Orchestration

Пользователь не получил SMS с кодом подтверждения платежа. Он пробует 3 раза - код не приходит. Банк теряет транзакцию. Проблема: push-канал был заблокирован системой, SMS-провайдер был в очереди за маркетинговой рассылкой. Orchestration - это то, что предотвращает такие ситуации.

• **PagerDuty:** строит 4-уровневую эскалацию push → email → SMS → phone call с таймаутами 30 сек, 5 мин, 5 мин. Обрабатывает >100 млн уведомлений в месяц для DevOps-команд по всему миру.
• **Airbnb:** хранит channel preferences в PostgreSQL, кеширует в Redis (TTL 5 мин). При 150 млн пользователей прямые запросы к БД на каждое уведомление создали бы неподъёмную нагрузку.
• **Duolingo:** персонализирует время доставки push-уведомлений на основе исторической активности пользователя - open rate вырос в 3x по сравнению с фиксированным расписанием.
• **Stripe:** для платёжных уведомлений использует push + email одновременно без fallback - оба канала важны. SMS только для 2FA OTP. Разделение по категориям экономит $2-5M в год на SMS-расходах.

Multi-channel доставка

Современные приложения доставляют уведомления через несколько каналов одновременно: push, email, SMS, in-app, Slack, WhatsApp. Проблема не в том, чтобы использовать все каналы, а в том, чтобы выбрать правильный канал для каждого события и каждого пользователя. Отправить SMS о лайке - раздражение. Не отправить SMS о критической ошибке платежа - потеря доверия.

Twilio обрабатывает >1 млрд SMS в месяц. Их внутренняя статистика: SMS в Индии стоит $0.014, в США - $0.0079, в Германии - $0.08. Выбор канала напрямую влияет на unit economics продукта. Компания Duolingo перешла с SMS-уведомлений на push и сэкономила $2 млн в год.

Orchestration-слой принимает решение о канале на основе: типа события (транзакционное vs маркетинговое), предпочтений пользователя, его текущего статуса (онлайн/офлайн), истории взаимодействий с каналом (открывал ли он email последние 30 дней).

Channel Preferences пользователя

Preferences - это не просто 'включить/выключить email'. Это двумерная матрица: тип уведомления x канал. Пользователь может хотеть получать платёжные уведомления на email, упоминания - через push, а маркетинг - нигде. Хранение и применение этих настроек - нетривиальная задача при высокой нагрузке.

Airbnb хранит notification preferences в PostgreSQL, но кеширует их в Redis с TTL 5 минут. При масштабе 150 млн пользователей прямой запрос к БД на каждое уведомление создал бы 10-20k QPS только от одной читающей системы. Кеш снижает нагрузку на 95%+ при незначительной задержке обновления настроек.

Quiet Hours и временные зоны

Quiet hours - это окно времени, в которое система удерживает неcрочные уведомления. Главная сложность: пользователи живут в разных временных зонах, и 'не беспокоить с 22:00 до 8:00' означает разные UTC-интервалы для каждого из них. Отправить push в 3 ночи по местному времени - гарантированный uninstall.

Duolingo анализировал данные: уведомления отправленные в 'prime time' пользователя (обычно 19:00-21:00 по местному времени) имеют open rate в 3x выше, чем отправленные вне этого окна. Персонализация времени доставки на основе исторической активности пользователя - следующий шаг после базовых quiet hours.

Fallback Chain

Fallback chain - это цепочка резервных каналов. Если push не доставлен (пользователь офлайн, токен устарел, push отключён), система переключается на следующий канал. Без fallback критические уведомления теряются при любом сбое первичного канала.

FCM возвращает код 'UNREGISTERED' когда пользователь удалил приложение или переустановил без переноса токена. По данным Firebase, ~5-15% активных токенов в базе становятся невалидными за 30 дней. Система должна автоматически очищать устаревшие токены по этим сигналам, иначе они засоряют базу и искажают метрики доставки.

Итоги

• **Канал определяется типом события**: транзакционные - push+email, 2FA - SMS, маркетинг - только email; стоимость SMS ($0.05-0.08) делает его нецелесообразным для всего кроме критических сообщений.
• **Preferences кешируются**: прямые запросы к БД на каждое уведомление при миллионах пользователей невозможны - Redis с TTL 5 мин снижает нагрузку на 95%, но требует немедленной инвалидации при изменениях.
• **Fallback chain последовательна, не параллельна**: push → email → SMS означает переход к следующему каналу только при неудаче предыдущего, а не отправку во все каналы сразу.

Связанные темы

Orchestration уведомлений опирается на несколько смежных областей:

• Notification Fan-out — Fan-out (предыдущий урок) генерирует задачи для orchestrator - миллионы событий, которые нужно маршрутизировать по каналам
• Caching (Redis) — Preferences и quiet hours хранятся в Redis для быстрого чтения без обращения к основной БД на каждое уведомление
• Dead Letter Queue — Когда fallback chain исчерпывает все каналы, событие попадает в DLQ для последующего анализа и ручной обработки

Вопросы для размышления

• Пользователь в командировке в стране без интернета. Push не доходит, email он не проверяет. Ему нужно получить 2FA-код для входа в корпоративную систему. Как должна выглядеть fallback chain?
• Как определить оптимальный TTL для кеша channel preferences? Что происходит если TTL слишком короткий? Если слишком длинный?
• Продукт хочет добавить WhatsApp как канал уведомлений. Какие изменения в orchestrator потребуются, и какие edge cases возникнут?

Связанные уроки

• sd-10-microservices