Представьте: клиент оформил заказ на 1 млн рублей, но уведомление не дошло — менеджер потерял сделку из-за зависшего 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
| Канал | Время доставки | Надёжность | Требует разрешения | Лучше всего для |
|---|---|---|---|---|
| Минуты | 95–99% | Нет | Длинные детальные сообщения | |
| SMS | Секунды | 99% | Да | Критические оповещения (2FA) |
| Push | Секунды | 90–95% | Да | Быстрые напоминания |
| In-App | Мгновенно | 100% (внутри) | Нет | Уведомления внутри приложения |
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 мс.
Процесс внедрения и сроки
| Этап | Что делаем | Срок |
|---|---|---|
| Аналитика | Описываем типы уведомлений, выбираем провайдеров, проектируем схему БД | 1–2 дня |
| Проектирование | Настраиваем очередь, пишем сервис уведомлений, UI для настроек | 2–3 дня |
| Реализация Email и SMS | Интеграция SendGrid/Mailgun и SMSC/Twilio, шаблоны, обработка ошибок | +2 дня |
| Push (FCM + Web) | Service Worker, VAPID, обработка невалидных токенов | +2 дня |
| In-App + WebSocket | Сохранение в БД, real-time push через Laravel Echo | +2 дня |
| Тестирование и деплой | Нагрузочное тестирование, мониторинг, документация | +1–2 дня |
| Полная система | Все каналы, UI, очереди, повторы | 7–10 дней |
Типичные ошибки и как их избежать
- Неправильный порядок очередей: Email и Push на одном воркере — при большом объёме Email блокирует Push. Решение: выделенные очереди. - Отсутствие дедупликации: при повторном клике на «Отправить» пользователь получает дубли. Решение: проверять по хешу события. - Игнорирование rate limit провайдера: FCM лимитирует 600 000 запросов/сек, но для SMS лимит ниже. Настраиваем семафор.Как избежать дублирования уведомлений?
Используем уникальный идентификатор события (UUID). Перед отправкой проверяем, не обрабатывалось ли уже такое событие. Если да — пропускаем.
Свяжитесь с нами для оценки проекта — получите консультацию за 2 дня. Мы гарантируем SLA 99.9% и предоставляем сертифицированных специалистов.