Multi-Channel Alerts: Email, SMS, Push & In-App Notifications

Picture this: a client places an order worth 1 million rubles, but the notification never arrives—the manager loses the deal because of a hung RabbitMQ. We build multi-channel notification systems that handle peak loads of 10,000 messages per minute and guarantee 99.9% delivery. Users choose their channels: Email, SMS, Push, In-App. The key tasks—centralized settings storage, sending queue, deduplication, and retry on failures. Over 5 years, we've deployed 50+ such systems for large e-commerce and SaaS platforms. Our notification system is designed to be a robust multi-channel notification system that ensures delivery even under heavy load.

Problems we solve

Without a queue, notifications get lost during peak loads: the database can't handle thousands of inserts, external APIs return 503 errors. Invalid push tokens accumulate—each notification to such a token wastes budget. Users complain about spam if settings don't allow disabling a channel. Our architecture solves all this.

Queue architecture: Guaranteed Delivery

The system is built around a queue (Redis or RabbitMQ). Each notification is a queue job. If the external service is temporarily unavailable, the job retries with exponential backoff. After three failures—it goes to a Dead Letter Queue for manual inspection.

[Event: OrderShipped] ↓ [NotificationService] ├── Check user preferences ├── Email: enqueue → SendGrid/Mailgun ├── SMS: enqueue → SMSC/Twilio ├── Push: enqueue → Firebase FCM └── In-App: save to DB → WebSocket push 

Channel comparison: Email, SMS, Push, In-App

Push notifications achieve 3x higher open rates than email, making them better for urgent alerts. According to Firebase documentation, push notification delivery rates exceed 90%. SMS is 10 times faster than email for critical alerts, but costs more.

Implementation in 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'); } } } 

Provider configuration

Email: templates and providers

For Email we use SendGrid (or Mailgun) with ready-made Blade templates. Each notification type is a separate mailable class. It's important to set up open and click tracking.

SMS: SMSC.ru and Twilio

For Russia—SMSC.ru, HTTP request with login and password. For international—Twilio. Both are wrapped in a queue with retries on 500 errors.

Push: Firebase FCM and Web Push

Firebase Cloud Messaging sends notifications to Android, iOS, and Web (via Service Worker). We remove invalid tokens from the database after FCM response. For Web Push, we use VAPID keys.

Client-side implementation: Web Push and notification center

Web Push: Service Worker subscription

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: real-time notification center

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={`Notifications: ${unread} 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> ); } 

The Danger of N+1 Queries in Notification Systems

When fetching the notification list, don't query each user separately—use eager loading. We check all queries via Laravel Debugbar and optimize indexes. This reduces API response time from 2 seconds to 50 ms.

Step-by-Step Integration Guide

1. Analyze requirements: Define notification types, channels, and target audience.
2. Design database schema: Create tables for notifications, preferences, and push tokens.
3. Implement queue: Set up Redis or RabbitMQ and configure worker processes.
4. Integrate providers: Connect SendGrid, Twilio, FCM, and SMSC.ru with proper error handling.
5. Build user interface: Develop settings page and notification center.
6. Test and deploy: Perform load testing and deploy with monitoring.

Implementation process and timelines

What's Included in the Deliverables

• Detailed documentation of notification flows
• Access to admin panel with user management
• Codebase with commented code
• 1 month post-launch support
• Performance monitoring setup
• SLA guarantee: 99.9% uptime

Clients save on average $12,000 per year by preventing missed notifications. Typical project cost ranges from $5,000 to $15,000 depending on channels and complexity.

How to avoid duplicate notifications?

We use a unique event identifier (UUID). Before sending, we check if the event has already been processed. If yes—skip.

Contact us for a project estimate—get a consultation within 2 days. We guarantee 99.9% SLA and provide certified specialists.