Мультиканальна система сповіщень: Email, SMS, Push, In-App

Уявіть: клієнт оформив замовлення на 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

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% та надаємо сертифікованих спеціалістів.