Notification system дизайн на собеседовании системного аналитика

Постановка задачи

Send notifications: order shipped, friend request, password reset.

Constraints:

• Multiple channels (email, SMS, push, in-app).
• Per-user preferences.
• Templates per language / locale.
• Reliability — не lose critical (password reset).

Архитектура

Event (OrderShipped) → Notification Service → Queue → Workers → Channel providers (Email, SMS, FCM, ...)
                                                              → Audit log

Async — workers process queue. Channels могут быть slow.

Multi-region. Failover providers.

Channels

Email. SES / SendGrid / Mailgun / Yandex Cloud Mail. Slow, batchable.

SMS. Twilio / SMSC.RU. Expensive, time-critical.

Push. FCM (Android), APNS (iOS).

In-app. Database table — show в UI.

Telegram bot. Messenger integration.

Каждый channel — separate worker / queue, independent rate limits.

User preferences

Per-user / per-event-type opt-in.

user 42:
  order_shipped: email + push
  marketing: email only
  security: всегда + critical bypass preferences

Quiet hours. Не send 22:00-08:00.

Frequency caps. Max N notifications per day.

Retry / dedup

Failed delivery → retry с backoff.

Attempt 1: 0
Attempt 2: 30s
Attempt 3: 5min
Attempt 4: 1h
Drop / DLQ.

Idempotency на receiving side — не send duplicate.

Notification ID + receiver — primary key.

Templating и i18n

Templates с placeholders.

"Hello {{name}}, your order #{{order_id}} shipped!"

Per language. Same template, different translations.

Per channel. Email — HTML+text. SMS — short. Push — title + body.

Tools: Mustache, Liquid, Handlebars.

Validation. Placeholders match data, no XSS.

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

• Webhook design для SA
• API Gateway и BFF для SA
• Idempotency key для SA
• Rate limiting для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на индустриальных notification system practices.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.