Кейс 1,8+ млн отправок в год и 0 потерянных писем: как мы разработали собственный сервис для рассылок

Решение

Создан единый сервис рассылок, который:

• принимает запросы на отправку от внутренних и клиентских сервисов по единому интерфейсу;
• маршрутизирует отправку через активного провайдера (с резервированием);
• хранит историю отправок, статусы и детали сообщений;
• дает администрирование доступа (API-клиенты и менеджеры);
• поддерживает конструктор шаблонов для ускорения запуска новых коммуникаций без участия всей команды разработки на каждом шаге.

Пример использования бизнес-логики

Например, у нас есть сторонний сервис, который отправляет документы. В зависимости от того, какая организация обращается в этот сервис, мы должны определить, есть ли у неё доступ к скачиванию определённого файла. Если доступ есть, мы скачиваем файл и прикрепляем его к письму. Если же доступа нет, мы просто отправляем ссылку, чтобы они могли авторизоваться и скачать файл в личном кабинете.

Такой набор бизнес-логик должен быть разработан на агрегаторе, который стоит между конечным отправителем и клиентом. Это также одна из причин, по которой нам был нужен сервис рассылок.

Архитектурная схема проекта

Функциональные возможности сервиса

Вход в сервис выполняется через единый сервис авторизации и регистрации (сквозная авторизация).

Основные разделы интерфейса:

• Пользователи
• Письма
• SMS
• Ошибки писем
• (Дополнительно в админ-части) белый список адресов для тестового окружения, логи и настройки шаблонов

Пользователи

В сервисе предусмотрены два типа пользователей:

• API-пользователи (внутренние сервисы компании) — работают с сервисом рассылок по API и инициируют отправки;
• Менеджеры — администрируют сервис: заводят API-пользователей, управляют доступами и настройками.

Менеджер вручную заводит нового API-пользователя по реквизитам. По пользователям доступны поиск, группировка и агрегированные данные по активности отправок — чтобы контролировать, что рассылки выполняются корректно.

Также гибкая ролевая модель позволяет управлять правами пользователей на: 

• отправка по email
• отправка sms
• отправка инцидентов;

Письма

Раздел содержит все e-mail, проходящие через сервис. Доступны:

• фильтры по шаблону/статусу/дате и поиск по данным отправки;
• просмотр карточки письма (идентификатор, дата, API-клиент, отправитель, шаблон, статус, тело письма, получатели и детальные статусы);
• возможность временно отключать шаблоны, чтобы «гасить» нежелательные отправки (запрос до сервиса доходит, но не уходит дальше по маршруту).

  

Шаблоны писем используются для того, чтобы не передавать по сети большой объем данных.
Под отдельные шаблоны допускается специфическая обработка параметров: сервис может дополнять данные для письма, исходя из входного набора.

SMS

SMS-рассылки поддерживают приоритизацию в зависимости от сценария:

• регулярные уведомления (например, статистика/отчеты);
• приоритетные события (например, вход/доступ в личный кабинет).

Доступны фильтры, просмотр деталей SMS и статусов по получателям.

Ошибки и надежность доставки

• При большом объеме сообщения попадают в очередь и обрабатываются согласно приоритетам.<
• При неуспешной отправке сообщения фиксируются в ошибках, а поддержка получает уведомления. Далее осуществляются попытки переотправки: первые 5 попыток через минуту каждая, 6ая попытка через 5 минут, 7ая -  20 минут, 8ая - 60 минут, 9ая  - 150 минут, 10ая - 300минут,  11ая - 720 минут. После задача попадает в список неуспешно отработанных задач.
• Реализован механизм защиты от «аномальных» отправок: для каждого внутреннего сервиса задаются пороги обращений, чтобы временно ограничить поток, если какой-то источник начинает слать избыточные уведомления.
• На уровне маршрутизации предусмотрены повторные попытки отправки и переключение на резервный канал при недоставке через основной.
• Также имеется возможность проанализировать причины ошибок при неуспешной отправки.

  

Конструктор шаблонов и ускорение запуска новых писем

В сервис добавлен конструктор шаблонов, позволяющий менеджерам собирать письма в интерфейсе и передавать разработчикам готовый формат интеграции (пример запроса и ожидаемого ответа).

Цель — уменьшить количество шагов с участием разработки при запуске нового письма: вместо последовательности «дизайн → верстка → backend → интеграция» бизнес получает возможность собрать шаблон и отдать разработчику только параметры для отправки.

Гибкая настройка интеграций и параметров API

В административной части доступны преднастройки параметров интеграции: для каждого API-клиента или сценария можно задать структуру и тело запроса, который отправляется от API-клиента в сервис рассылок, включая обязательные параметры и формат передаваемых данных.

Это позволяет:

• быстро адаптироваться к изменениям требований и API внешних провайдеров за счёт централизованных настроек и преднастроек запросов;
• подключать новых отправщиков без изменений в интеграциях внутренних систем: достаточно реализовать отдельный адаптер (реализацию нашего программного интерфейса) для нового провайдера и включить его в маршрутизацию.