Сервис рассылок на Laravel: как мы объединили отправку email и SMS для всех внутренних сервисов

Проблема: рассылки как узкое место команды

Начнём с контекста. Мы участвовали в крупном проекте: наборе различных кабинетов на платформе «1С-Битрикс». Каждое решение выполняло свою роль. Авторизация в каждое решение происходила по OAuth 2.0 через наш модуль на Laravel. Большинство сервисов отправляли клиентам письма на email, часть использовали ещё и SMS-сообщения.

На первый взгляд всё работало. Но при ближайшем рассмотрении накапливался технический долг:

• Каждый сервис имел собственную интеграцию с провайдерами рассылок. Один и тот же код отправки дублировался в каждом решении.

• Поддержка была единой, но код отправки размазан по всем сервисам — исправлять ошибки приходилось в нескольких местах.

• Не было дашборда. Невозможно было понять, ушло ли сообщение и в каком оно статусе.

• Доработки отправок вносились в каждый сервис отдельно. При загруженности команды бизнес долго ждал правок.

Каждая новая правка превращалась в мини-проект: синхронно менять несколько сервисов, тестировать каждую интеграцию и держать в голове, где какой провайдер подключён.

Идея: не модуль, а единый сервис

Изначально задача звучала скромно — разработать модуль рассылок для сервиса авторизации. Но мы предложили бизнесу пойти дальше: сделать единый сервис рассылок для всех внутренних сервисов. Идею одобрили.

Почему это выгоднее, чем очередной модуль:

• Одна интеграция вместо нескольких. Провайдеры подключаются один раз, а не в каждом сервисе.

• Единый формат API для всех внутренних сервисов. Отправка и получение статуса — по одному протоколу.

• Централизованный дашборд статусов отправок и лог ошибок. Поддержка могла видеть информацию по отправкам.

• Правки шаблонов и логики — в одном месте. Бизнес получает изменения быстрее.

Дополнительный триггер: все сервисы использовали для отправок Mailchimp, и требовалось перейти на новое решение для РФ-сегмента — так как ожидалась блокировка Mailchimp.

Архитектура сервиса рассылок

Мы разделили сервис на три решения. Каждое выполняет свою роль и взаимодействует с остальными по чётким контрактам.

1. Дашборд — веб-интерфейс

Решение доступно из веб-браузера. Здесь сосредоточена вся операционная картина:

• данные по отправкам email и SMS;

• API-клиенты сервиса и действия над ними;

• лог ошибок;

• шаблоны писем и сообщений.

Именно здесь фронтенд-специалист готовит и правит шаблоны.

2. API-решение

Принимает задачу на отправку по каналу: инциденты(в омнитрэкер), email(интеграции с DashaMailm Unisender, собственный сервис рассылок) или SMS((интеграции с МТС Маркетолог, МТС Communicator). После валидации запроса инициирует создание Jobs в RabbitMQ.

3. Решение для отправки

Единственный интерфейс взаимодействия с ним — задачи в RabbitMQ. Это решение берёт задачи из очереди, когда они там появляются. За шаблонами оно обращается к первому решению (дашборду) по API протоколу.

Такое разделение сделало систему гибкой: отправитель не знает ничего об API и дашборде, а работает только с очередью. Это упрощает масштабирование и изоляцию сбоев.

Как это работает на практике

Опишем полный цикл — от правки шаблона до получения статуса отправки.

1. Бизнесу нужно изменить шаблон письма или разработать новый.

2. Фронтенд-специалист готовит шаблон или меняет его в блоке, который отвечает за шаблоны. Релизим правки.

3. Выдаём инструкцию внутренним сервисам, как пользоваться новым или изменённым шаблоном по API-протоколу: отправка письма и получение статуса письма.

4. Клиентский сервис обращается по API, инициирует отправку. Сервис рассылок валидирует запрос и кладёт задачу в очередь на отправку, затем обрабатывает заявку.

5. Сервис ожидает данные по статусу отправки по вебхукам от агрегаторов.

К сервису подключены три агрегатора для email и два для SMS. Такая схема даёт резервирование: если один провайдер недоступен, отправка уходит через другой.

Почему RabbitMQ

Очередь сообщений стала связующим звеном между API-решением и отправителем. Это дало несколько важных преимуществ:

• Асинхронность. Клиентский сервис не ждёт, пока письмо реально уйдёт, — он получает подтверждение о приёме задачи.

• Надёжность. Задачи не теряются при сбоях, очередь хранит их до обработки.

• Разделение ответственности. Отправитель можно масштабировать независимо от остальных компонентов.

Вожно, в самом RabbitMQ мы настроили удаление задачи только в случае успешного выполнения задачи дабы избежать утери задач, которые принялись в обработку, но не выполнились.

Что это дало бизнесу и команде

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

Главные результаты:

• Сократилось время на работу над отправками на внутренних сервисах.

• Высвободившееся время команды направили на более важные фичи для бизнеса.

• Появилась прозрачность. Дашборд показывает статусы отправок, которых раньше не было видно.

• Правки шаблонов стали быстрыми. Бизнес больше не ждёт долго — изменение вносится в одном месте.

Заключение

Ключевые уроки, которые мы вынесли из этого проекта:

• Централизация рассылок окупается, когда сервисов несколько и интеграции дублируются. Один сервис вместо нескольких — это меньше кода, меньше ошибок и быстрее доработки.

• Разделение на дашборд, API и отправителя через очередь делает систему гибкой и масштабируемой. Каждый компонент можно менять и развивать независимо.

• Вебхуки от агрегаторов дают прозрачность статусов, которой раньше не было. Бизнес видит, ушло ли сообщение.

• Стоит предлагать бизнесу более широкое решение. Задача «сделать модуль» превратилась в архитектурное улучшение, которое сэкономило время всей команды.

Если у вас несколько сервисов, каждый из которых по-своему отправляет email и SMS, — присмотритесь к единому сервису рассылок. Это тот случай, когда вложение в архитектуру окупается быстро.