Мультиканальная система уведомлений: 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% и предоставляем сертифицированных специалистов.