Как бы вы спроектировали общекорпоративный сервис уведомлений?

Question

IT Interview Practice · Accepted Answer

Постройте один сервис, который каждая команда вызывает с **типом уведомления + получателем**, а сервис сам разрешает канал, шаблон, пользовательские настройки и приоритет. Ключевой архитектурный ход — **приоритетные полосы (priority lanes)**: OTP не может ждать за маркетинговой рассылкой на 2 млн пользователей.

## Архитектура

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

## Компоненты и поток

- **Notify API** принимает типизированный запрос: `{type: "otp", user, data}`. Вызывающие никогда не выбирают канал и не пишут текст — этим владеет сервис, поэтому изменение шаблона выкатывается один раз.
- **Тип → политика**: каждый **тип** сопоставлен с политикой. *OTP* — высокий приоритет, SMS+Push, игнорирует маркетинговый opt-out, истекает за 60 с. *Транзакционные* (чек, сброс пароля) — высокий приоритет, уважают настройки каналов. *Маркетинг* — низкий приоритет, bulk-полоса, строго соблюдает opt-out и quiet hours.
- **Приоритетные полосы** — это отдельные топики Kafka с отдельными consumer-группами. Высокая полоса остаётся почти пустой и опустошается за миллисекунды; bulk-полоса может копиться минутами, не затрагивая latency OTP. Это единственное самое важное решение.
- **Сервис настроек (preferences)** проверяется для каждого получателя: отписался? quiet hours? тумблер по каналу? частотный лимит? Маркетинг, нарушающий настройку, отбрасывается здесь.
- **Шаблонизатор** рендерит локализованный контент из версионированного шаблона + переменных, так что текст и код разделены.
- **Адаптеры каналов** оборачивают FCM/APNs, SendGrid, Twilio за единым интерфейсом, у каждого — свой rate limiter, повторы и DLQ (та же дисциплина fan-out, что у любого bulk-отправителя).

## Взгляд с точки зрения интервью

Интервьюеры проверяют, разделяете ли вы **ответственности**: многие кандидаты строят монолит, который шлёт email напрямую, а потом обнаруживают, что маркетинговые потоки задерживают OTP. Назвать *приоритетные полосы*, *принуждение к соблюдению настроек* и *ключи идемпотентности* (чтобы повторённый запрос не уведомлял дважды) — это senior-сигнал. «Хорошо» добавляет каналы; «отлично» объясняет, почему OTP и маркетинг никогда не должны делить очередь, и как работает **цепочка fallback** (Push не удался → SMS).

## Компромиссы и отказы

- **Один сервис против решения на команду**: централизация даёт единые настройки, троттлинг и аудит, но становится критической зависимостью — она должна быть HA, иначе отказ OTP при логине блокирует всю компанию.
- **Реальное время против стоимости**: SMS дорого и медленно; предпочитайте Push/In-App, а к SMS откатывайтесь только для высокоценных типов.
- **Отказ**: сбой провайдера запускает цепочку fallback, а не жёсткий отказ. **Ключи дедупликации** не дают повторной доставке очереди отправить OTP дважды. Отслеживайте SLO доставки по типам — задержанный маркетинговый email нормален, задержанный OTP — это инцидент.

Архитектура

Компоненты и поток

Взгляд с точки зрения интервью

Компромиссы и отказы

Похожие вопросы