Мультиканальная система уведомлений: Email, SMS, Push, In-App

Представьте: клиент оформил заказ на $9k–13k, но уведомление не дошло — менеджер потерял сделку из-за зависшего RabbitMQ. Мы строим мультиканальную систему уведомлений, которая выдержит пиковую нагрузку в 10 000 сообщений в минуту и обеспечит доставку 99.9% сообщений. Пользователь сам выбирает каналы: Email, SMS, Push, In-App. Ключевые задачи — централизованное хранилище настроек, очередь отправки, дедупликация и повтор при сбоях. За 5 лет мы внедрили 50+ таких систем для крупных интернет-магазинов и SaaS-платформ.

Проблемы, которые решаем

Без очереди уведомления теряются при пиковой нагрузке: база не справляется с тысячами вставок, внешние API возвращают 503 ошибки. Невалидные push-токены копятся — каждое уведомление на такой токен тратит бюджет. Пользователи жалуются на спам, если настройки не дают отключить канал. Наша архитектура решает всё это.

Архитектура очереди: как гарантировать доставку?

Система строится вокруг очереди (Redis или RabbitMQ). Каждое уведомление — задача в очереди. Если внешний сервис временно недоступен, задача повторяется с экспоненциальной задержкой. После трёх неудач — в Dead Letter Queue для ручного разбора.

[Event: OrderShipped] ↓ [NotificationService]
├── Проверить настройки пользователя
├── Email: в очередь → SendGrid/Mailgun
├── SMS: в очередь → SMSC/Twilio
├── Push: в очередь → Firebase FCM
└── In-App: сохранить в БД → WebSocket push

Сравнение каналов: Email, SMS, Push, In-App

Push-уведомления доставляются за секунды, тогда как Email может задерживаться на минуты из-за очередей провайдера. SMS — самый быстрый, но дорогой канал.

Реализация на Laravel

class NotificationService {
    public function notify(User $user, string $type, array $payload): void {
        $prefs = NotificationPreference::where('user_id', $user->id)
            ->where('notification_type', $type)
            ->first();

        $defaults = [
            'email_enabled' => true,
            'sms_enabled' => false,
            'push_enabled' => true,
            'inapp_enabled' => true,
        ];

        $channels = array_merge($defaults, $prefs?->toArray() ?? []);

        if ($channels['inapp_enabled']) {
            $notification = Notification::create([
                'user_id' => $user->id,
                'type' => $type,
                'title' => $payload['title'] ?? null,
                'body' => $payload['body'] ?? null,
                'data' => $payload['data'] ?? [],
            ]);

            broadcast(new NewNotificationEvent($user, $notification))->toOthers();
        }

        if ($channels['email_enabled'] && isset($payload['email'])) {
            SendEmailNotificationJob::dispatch($user, $type, $payload['email'])->onQueue('notifications');
        }

        if ($channels['sms_enabled'] && $user->phone && isset($payload['sms'])) {
            SendSmsNotificationJob::dispatch($user, $payload['sms'])->onQueue('notifications');
        }

        if ($channels['push_enabled'] && isset($payload['push'])) {
            SendPushNotificationJob::dispatch($user, $payload['push'])->onQueue('notifications');
        }
    }
}

Настройка провайдеров

Email: шаблоны и провайдеры

Для Email используем SendGrid (или Mailgun) с готовыми шаблонами в Blade. Каждый тип уведомления — отдельный mailable класс. Важно настроить отслеживание открытий и кликов.

SMS: SMSC.ru и Twilio

Для России — SMSC.ru, HTTP-запрос с логином и паролем. Для международных — Twilio. Оба обёрнуты в очередь с повторами при 500-х ошибках.

Push: Firebase FCM и Web Push

Firebase Cloud Messaging отправляет уведомления на Android, iOS и Web (через Service Worker). Мы удаляем невалидные токены из базы после ответа FCM. Для Web Push используется VAPID-ключи.

Реализация клиентской стороны: Web Push и центр уведомлений

Web Push: Service Worker подписка

async function subscribeToPush(): Promise<void> {
  const registration = await navigator.serviceWorker.ready;
  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: urlBase64ToUint8Array(import.meta.env.VITE_VAPID_PUBLIC_KEY),
  });
  await api.post('/api/push-tokens', {
    token: JSON.stringify(subscription),
    platform: 'web',
  });
}

React: центр уведомлений в реальном времени

function NotificationCenter() {
  const { data, refetch } = useQuery({
    queryKey: ['notifications'],
    queryFn: fetchNotifications
  });
  const unread = data?.filter(n => !n.read_at).length ?? 0;
  useEffect(() => {
    const echo = window.Echo.private(`notifications.${currentUser.id}`)
      .listen('NewNotificationEvent', () => refetch());
    return () => echo.stopListening('NewNotificationEvent');
  }, []);
  return (
    <div className="notification-center">
      <button className="bell" aria-label={`Уведомления: ${unread} непрочитанных`}>
        <BellIcon />
        {unread > 0 && <span className="badge">{unread > 99 ? '99+' : unread}</span>}
      </button>
      <ul className="notification-list">
        {data?.map(notification => (
          <li key={notification.id} className={notification.read_at ? '' : 'unread'}>
            <span>{notification.title}</span>
            <time>{timeAgo(notification.created_at)}</time>
          </li>
        ))}
      </ul>
    </div>
  );
}

Почему N+1 запрос опасен в системе уведомлений?

При получении списка уведомлений не делайте запрос по каждому пользователю отдельно — используйте eager loading. Мы проверяем все запросы через Laravel Debugbar и оптимизируем индексы. Это сокращает время отклика API с 2 секунд до 50 мс.

Процесс внедрения и сроки

Как избежать дублирования уведомлений?

Используем уникальный идентификатор события (UUID). Перед отправкой проверяем, не обрабатывалось ли уже такое событие. Если да — пропускаем.

Свяжитесь с нами для оценки проекта — получите консультацию за 2 дня. Мы гарантируем SLA 99.9% и предоставляем сертифицированных специалистов.