Что нужно уточнить в первые минуты
Начните не с Kafka и воркеров, а с требований: какие каналы нужны, что считается доставкой, нужна ли персонализация, есть ли scheduled notifications и какой порядок приоритетов.
Отдельно зафиксируйте масштаб: число пользователей, пиковые события, допустимую задержку, SLA внешних провайдеров и требования к audit trail. Это сразу задаёт рамку решения и показывает интервьюеру, что вы проектируете систему, а не перечисляете технологии.
Базовая архитектура
Надёжная схема обычно включает API Gateway, Notification API, сервис шаблонов, preference service, очередь, набор воркеров по каналам и таблицу delivery attempts. API принимает событие, валидирует права, нормализует payload и кладёт задачу в очередь.
Воркеры читают задачи, применяют rate limits провайдеров, отправляют email, push, SMS или in-app уведомление и записывают статус попытки. Такой слой изолирует продуктовую систему от нестабильности внешних API.
Очереди, retry и идемпотентность
Очередь нужна не только для нагрузки. Она даёт backpressure, повторные попытки, dead-letter queue и возможность разделить приоритетные события от массовых рассылок.
Каждое уведомление должно иметь idempotency key. Если событие пришло повторно или воркер перезапустился после частичной отправки, система не должна отправить пользователю два одинаковых сообщения без причины.
Что проговорить на интервью
Обязательно назовите компромиссы: exactly-once почти всегда заменяется практичной комбинацией at-least-once delivery, идемпотентности и дедупликации. Для срочных уведомлений нужны отдельные очереди и лимиты, для массовых — batch processing и throttle.
Завершите ответ наблюдаемостью: метрики очередей, latency по каналам, error budget, процент успешных доставок, провайдерские ошибки и алерты по росту DLQ. Это превращает архитектуру из рисунка в управляемую систему.
