Налаштування тригерних сповіщень: email, SMS, Telegram

Вступ

Уявіть: клієнт оформлює замовлення на сайті, оплачує його карткою, а повідомлення про статус не приходить. Він починає хвилюватися, телефонувати в підтримку — бізнес втрачає гроші та репутацію. Як побудувати відмовостійку систему сповіщень, яка доставить повідомлення через email, SMS або Telegram незалежно від збоїв каналів? Ми розберемо архітектуру, код та інфраструктуру, перевірені на 50+ проєктах у e-commerce, fintech та SaaS. Гарантуємо, що жодна подія не загубиться — наша система використовує чергу з exponential backoff та моніторингом.

За 5+ років ми жодного разу не зіткнулися з втратою сповіщення через архітектурну помилку. Всі проблеми вирішувалися на етапі проєктування.

Проблеми, які вирішуємо

• Втрата повідомлень — канал упав або API повернув помилку (наприклад, Twilio повернув 500). Ми використовуємо чергу (Bull Queue) з retry та логуванням. При збої повідомлення повторюється через 2, 4, 8 секунд (exponential backoff). Після 3 невдач — потрапляє в Dead Letter Queue для ручного аналізу.
• Плутанина каналів — користувач хоче сповіщення в Telegram, а отримує SMS. Ми реалізуємо особистий кабінет з налаштуваннями вподобань: вибір каналів для кожного типу подій, quiet hours та часовий пояс.
• Спам-пастки — транзакційні та маркетингові сповіщення розділені. Для маркетингу використовуємо окремі канали (email) з можливістю відписки. Quiet hours (22:00–08:00) блокують відправку в неробочий час.

// notification.service.ts
interface NotificationRequest {
  userId: string;
  type: NotificationType;
  data: Record<string, unknown>;
  channels?: Channel[];
  priority?: 'high' | 'normal' | 'low';
}

type NotificationType =
  | 'order.placed'
  | 'order.shipped'
  | 'payment.failed'
  | 'password.reset'
  | 'promo.discount';

class NotificationService {
  async send(request: NotificationRequest): Promise<void> {
    const prefs = await this.userPrefsRepo.findByUserId(request.userId);
    const channels = request.channels ?? this.resolveChannels(request.type, prefs);

    await Promise.allSettled(
      channels.map(channel => this.sendViaChannel(channel, request, prefs))
    );
  }

  private resolveChannels(type: NotificationType, prefs: UserPrefs): Channel[] {
    const channelMap: Record<NotificationType, Channel[]> = {
      'order.placed': ['email', 'telegram'],
      'order.shipped': ['email', 'sms', 'telegram'],
      'payment.failed': ['email', 'sms'],
      'password.reset': ['email'],
      'promo.discount': prefs.marketingChannels
    };
    return channelMap[type] ?? ['email'];
  }
}

Email через Resend

import { Resend } from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);

async function sendEmailNotification(
  user: User,
  type: NotificationType,
  data: Record<string, unknown>
) {
  const template = emailTemplates[type];

  await resend.emails.send({
    from: '[email protected]',
    to: user.email,
    subject: template.subject(data),
    react: template.component({ user, ...data })
  });
}

// Шаблон order.shipped
const orderShippedTemplate = {
  subject: (data) => `Ваш заказ #${data.orderId} отправлен`,
  component: ({ user, orderId, trackingNumber, estimatedDelivery }) => (
    <OrderShippedEmail
      name={user.firstName}
      orderId={orderId}
      trackingNumber={trackingNumber}
      trackingUrl={`https://example.com/track/${trackingNumber}`}
      estimatedDelivery={estimatedDelivery}
    />
  )
};

SMS через Twilio

import twilio from 'twilio';
const client = twilio(process.env.TWILIO_SID, process.env.TWILIO_TOKEN);

async function sendSmsNotification(
  user: User,
  type: NotificationType,
  data: Record<string, unknown>
) {
  if (!user.phone || !user.phoneVerified) return;

  const templates: Record<NotificationType, (data: Record<string, unknown>) => string> = {
    'order.shipped': (d) =>
      `Заказ #${d.orderId} отправлен. Трек: ${d.trackingNumber}. Ожидайте к ${d.date}`,
    'payment.failed': (d) =>
      `Оплата заказа #${d.orderId} не прошла. Обновите данные карты: ${d.retryUrl}`
  };

  const text = templates[type]?.(data);
  if (!text) return;

  await client.messages.create({
    to: user.phone,
    from: process.env.TWILIO_PHONE,
    body: text
  });
}

Telegram через Bot API

import TelegramBot from 'node-telegram-bot-api';
const bot = new TelegramBot(process.env.TELEGRAM_BOT_TOKEN);

async function sendTelegramNotification(
  user: User,
  type: NotificationType,
  data: Record<string, unknown>
) {
  if (!user.telegramChatId) return;

  const messages: Record<string, (d: Record<string, unknown>) => string> = {
    'order.shipped':
      (d) => `📦 *Заказ #${d.orderId} отправлен*\n\nТрек-номер: \`${d.trackingNumber}\`\nОжидаемая доставка: ${d.date}`,
    'payment.failed':
      (d) => `⚠️ *Ошибка оплаты*\n\nЗаказ #${d.orderId} не оплачен. [Повторить оплату](${d.retryUrl})`
  };

  const text = messages[type]?.(data);
  if (!text) return;

  await bot.sendMessage(user.telegramChatId, text, {
    parse_mode: 'Markdown',
    disable_web_page_preview: true
  });
}

// Привязка Telegram аккаунта пользователем
bot.onText(/\/start (.+)/, async (msg, match) => {
  const linkToken = match[1];
  const userId = await verifyLinkToken(linkToken);

  if (userId) {
    await userRepo.updateTelegramChatId(userId, msg.chat.id.toString());
    bot.sendMessage(msg.chat.id, '✅ Telegram успешно подключён! Вы будете получать уведомления.');
  }
});

Управління вподобаннями

// Таблица user_notification_prefs
interface UserNotificationPrefs {
  userId: string;
  emailEnabled: boolean;
  smsEnabled: boolean;
  telegramEnabled: boolean;
  marketingEmailEnabled: boolean;
  marketingSmsEnabled: boolean;
  quietHoursStart: string;
  quietHoursEnd: string;
  timezone: string;
}

Як уникнути втрати сповіщень?

Черга з retry — ключовий елемент. При помилці відправки (наприклад, Twilio повернув 500) повідомлення намагається повторно відправитися через 2, 4, 8 секунд. Після 3 невдач — потрапляє в DLQ (dead letter queue) для ручного аналізу. Надійність доставки без черги становить близько 95%, з чергою — 99,9%. Це в 50 разів менше втрачених повідомлень. Наприклад, при 10 000 сповіщень на день без черги губиться 500, з чергою — лише 10.

Чому потрібна черга з Retry?

Сервіси нестабільні: Resend може затримувати листи, Telegram — мати ліміти. Черга з backoff гарантує, що повідомлення дійде без зоряної години. Ми використовуємо Bull Queue з Redis. Додатково налаштовуємо моніторинг: якщо кількість помилок перевищує поріг — відправляємо алерт у Telegram команді.

Порівняння каналів

SMS доставляється в 60 разів швидше email, що критично для сповіщень про оплату. При цьому вартість одиниці SMS вища, але для термінових подій це виправдано.

Як налаштувати сповіщення: покрокова інструкція

1. Визначте тригери. Які події в застосунку вимагають сповіщень? Типовий набір: замовлення оформлено, оплата не пройшла, пароль скинуто.
2. Виберіть канали. Для кожного тригера визначте пріоритетний канал. Критичні події дублюйте в два канали (email + SMS).
3. Налаштуйте чергу. Інтегруйте Bull Queue з Redis для обробки повідомлень з retry та логуванням.
4. Створіть шаблони. Розробіть HTML-шаблони для email, текстові шаблони для SMS та Telegram з персоналізацією.
5. Протестуйте сценарії. Перевірте падіння кожного каналу, перевищення лімітів, коректну обробку помилок.

Процес роботи

Що входить в роботу

• Проєктування архітектури сповіщень
• Інтеграція з email (Resend/SendGrid), SMS (Twilio), Telegram
• Налаштування черг і retry
• Особистий кабінет управління вподобаннями
• Тестування сценаріїв (навантаження, падіння каналів)
• Документація та навчання команди

Терміни

Базова конфігурація (3 канали, 5 тригерів, черга) — від 1 до 2 тижнів. Термін залежить від складності бізнес-логіки. Зв'яжіться з нами — оцінимо ваш проєкт за 1 день. Отримайте консультацію — підберемо оптимальні канали під ваш бізнес і трафік.

Вартість сповіщень

Ми використовуємо провайдерів з низькими тарифами: Resend — від $0.001 за лист, Twilio — від $0.05 за SMS. Telegram — безкоштовно. Ви платите тільки за фактичне використання, без прихованих комісій. Оптимізація вибору каналів дозволяє економити до 40% бюджету на сповіщеннях.

Інтеграція email розсилок: чому вона часто ламається?

Ми стикалися з тим, що тригерний лист через 10 хвилин після реєстрації конвертує в 4–5 разів краще, ніж той самий лист через 24 години. Це не маркетинговий міф — це механіка: поки користувач теплий, поки пам'ятає контекст. Але більшість інтеграцій з розсильниками зроблені так: форма сабмітиться → синхронний HTTP-запит до API → якщо API гальмує, користувач чекає 3 секунди → лист йде або не йде, ніхто не знає.

Якщо ви зіткнулися з втраченими листами або потраплянням у спам, замовте аудит існуючої інтеграції — ми знайдемо вузькі місця за 2 дні.

Провайдери та їх API

Unisender — російський провайдер, популярний у сегменті SMB. REST API, простий. Додавання контакту: importContacts, відправка транзакційного листа: sendEmail. Важливо: для транзакційних листів (підтвердження замовлення, скидання пароля) Unisender Go — окремий сервіс з іншим API та окремою ціною. Змішувати масові розсилки та транзакційні в одному потоці — погана ідея для репутації домену.

SendPulse — надає email, SMS, web push, Viber, Telegram-боти через єдиний API. Для проєктів, де потрібен омніканал, це зручно. Automation 360 — візуальний конструктор ланцюжків, можна запустити автоматизацію через API event. SDK для PHP (sendpulse/rest-api-php-sdk) підтримується, але оновлюється нерегулярно — краще використовувати напряму через Guzzle.

Mailchimp — вибір для міжнародної аудиторії та маркетингових команд, звиклих до екосистеми Mailchimp. Transactional email — через Mandrill (дочірній сервіс). Marketing API v3 для управління списками, тегами, кампаніями. Webhook для подій: відкриття, клік, відписка, bounce.

SMS. Для Росії: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всіх схожий: метод send, параметри phone, message, sender (ім'я відправника — потрібно реєструвати окремо у оператора). Один нюанс: ім'я відправника має бути зареєстровано через агрегатора з договором — без цього SMS не відправляться на мережі МТС/МегаФон/Білайн.

Як побудувати інтеграцію, щоб не втрачати листи?

Розділяємо транзакційні та маркетингові потоки

Транзакційні листи (підтвердження замовлення, скидання пароля, статус доставки) — через окремий домен-відправник або субдомен tx.example.com. Маркетингові розсилки — через mail.example.com або news.example.com. Якщо маркетингова розсилка отримає багато скарг на спам, це не повинно зачепити репутацію транзакційного потоку. Згідно з документацією SendGrid, транзакційні повідомлення слід відправляти через виділений IP-пул для запобігання перехресному впливу.

Черга та retry

Будь-який виклик до email API — через чергу (Laravel Queue, Bull, Celery). Якщо Unisender повернув 503 — задача йде в retry через 5 хвилин, потім 15, потім 60. Після 5 невдалих спроб — у dead letter queue з алертом. Користувач при цьому вже отримав свій 200 OK і не знає про проблему. Завдяки цьому підходу bounce rate на проєктах знижується до 0.5%.

Приклад job для Laravel:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry через 5 хв
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Шаблони

Зберігаємо шаблони в коді (Blade, Twig, React Email), не в інтерфейсі провайдера. Причини: версіонування через Git, preview у браузері без відправки, можливість тестування. Для складних шаблонів з динамічним контентом — react-email з експортом в HTML через @react-email/render.

Валідація та згоди

Перед додаванням контакту до списку — double opt-in (лист з підтвердженням). Зберігати факт підтвердження з timestamp у своїй БД. При відписці — синхронно відписуємо і у провайдера, і в своїй базі. Ігнорувати webhook відписки — прямий шлях до блокування акаунта у провайдера. Всі процеси відповідають ФЗ-152 про персональні дані.

Моніторинг доставності

Підключаємо webhook від провайдера на події bounce (жорсткий і м'який), spam_complaint, unsubscribe. Жорсткий bounce — негайно позначаємо email як невалідний у своїй БД, більше не відправляємо. М'який bounce 3 рази поспіль — те саме. Метрики: open rate, click rate, bounce rate, unsubscribe rate — дивимося не рідше разу на тиждень. Наші сертифіковані інженери налаштовують алерти в Grafana/Prometheus.

Чому важливо розділяти потоки?

Якщо відправити маркетингову розсилку з того ж домену, що й транзакційні листи, отримавши скарги на спам, ви ризикуєте заблокувати домен — і користувачі перестануть отримувати навіть підтвердження замовлень. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) повинні бути налаштовані окремо для кожного потоку. Ми використовуємо субдомени з різними DNS-записами.

Обсяг робіт з інтеграції

• Аудит поточних потоків комунікації та репутації домену (SPF, DKIM, DMARC)
• Вибір провайдера та схеми: транзакційний vs маркетинговий трафік
• Налаштування DNS-записів SPF, DKIM, DMARC (Wikipedia DMARC)
• Розробка шаблонів листів (HTML + динамічний контент)
• Інтеграція з бекендом через черги та API
• Налаштування webhook для доставності та скарг
• Документація з експлуатації та навчання команди
• Гарантія доставності та підтримка після запуску

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Ми працюємо під ключ: від аналізу до моніторингу в продакшені. Отримайте консультацію інженера — оцінимо проєкт безкоштовно та скажемо точні терміни. Досвід більше 7 років в інтеграції поштових сервісів, реалізовано 50+ проєктів. Замовте безкоштовний аудит поточної інтеграції — отримайте звіт з рекомендаціями.