Откуда брать данные для уведомлений
Что проверяют
Умеете ли вы спроектировать поток данных, а не только написать отправку сообщения. Вопрос про то, откуда сервис уведомлений узнаёт о событии, и почему выбранный способ не теряет сообщения и не шлёт их дважды.
Как отвечать
Разделите данные на три части: событие (что случилось), получатель (кому и куда слать) и содержимое (чем наполнить шаблон).
Событие приходит одним из способов:
- подписка на брокер: сервис читает сообщения и реагирует. Основной вариант, когда событие рождается в другом сервисе;
- шаблон outbox: производитель в одной транзакции с бизнес-изменением пишет строку в таблицу исходящих, отдельный процесс её вычитывает и публикует. Так уведомление не уйдёт по откаченной транзакции и не потеряется при недоступности брокера;
- опрос по расписанию: напоминания, просроченные задачи, отчёты. В Python это обычно периодическая задача Celery или отдельный воркер с выборкой по условию;
- вебхук извне: платёж, доставка, смена статуса у поставщика.
Настройки получателя сервис берёт из своей базы или у сервиса профилей: канал, язык, часовой пояс, согласие на рассылку, тихие часы. В чужую базу напрямую лучше не ходить, надёжнее запросить по API и закэшировать.
Обязательно скажите про идемпотентность: у события есть ключ, по которому проверяется, что такое уведомление уже отправлено. Брокеры дают доставку минимум один раз, и без ключа пользователь получит письмо дважды.
Где спотыкаются
Кладут в событие весь текст письма. Событие раздувается, а после правки шаблона сообщения, уже лежащие в очереди, уйдут в старом виде. В событии держат идентификаторы и минимум полей, остальное дотягивают на момент отправки.
Отправляют письмо прямо в обработчике запроса. Внешний сервис тормозит, ответ пользователю висит, а при откате транзакции письмо уже ушло и отозвать его нельзя.
Забывают про согласие и отписку. Технически безупречная рассылка без проверки признака подписки даёт жалобы и портит репутацию домена отправителя.