Какие виды уведомлений используются в системах (SMS, push, email и т.д.)
Что проверяют
Вопрос выглядит как перечисление каналов, но на деле это заход в системный дизайн: как вы построите сервис уведомлений, который не теряет сообщения и не шлёт их дважды. Следом обычно просят набросать эту схему на Go.
Как отвечать
Коротко пройдите по каналам, у каждого своя цена и назначение:
- email: SMTP или HTTP API почтового провайдера. Дёшево, подходит для длинного текста и чеков, но письмо может уйти в спам;
- SMS: через SMS-агрегатора, платно за каждое сообщение. Нужны для кодов подтверждения и критичных событий;
- мобильный push: APNs для iOS и FCM для Android. Токены устройств устаревают, невалидные удаляют по ответу сервиса;
- web push: Push API и Service Worker с ключами VAPID, работает только после разрешения пользователя;
- in-app: лента уведомлений в продукте, онлайн-пользователю доставка по WebSocket или SSE;
- боты в мессенджерах и вебхуки: для B2B-клиентов и внутренних алертов.
Затем архитектура. Бизнес-сервис не шлёт уведомление сам, а пишет событие в очередь (Kafka, RabbitMQ, NATS), надёжнее через transactional outbox. Сервис уведомлений читает событие, проверяет настройки пользователя и тихие часы, рендерит шаблон через text/template или html/template и отдаёт воркеру нужного канала. Воркеры это пул горутин с context.WithTimeout на каждый вызов провайдера, ограничением частоты через golang.org/x/time/rate, ретраями с экспоненциальной задержкой и dead letter queue для безнадёжных сообщений.
Где спотыкаются
Отправляют уведомление синхронно прямо в HTTP-обработчике. Провайдер тормозит, и вместе с ним тормозит регистрация или оплата.
Забывают про идемпотентность. Очередь даёт доставку «хотя бы один раз», и без ключа дедупликации пользователь после ретраев получает три одинаковых SMS.
Игнорируют стоимость и правила каналов: шлют SMS там, где хватило бы push, не дают отписаться от рассылок и не учитывают лимиты провайдера на частоту.