Как мы отстояли клиентов: история одного перехода между агрегаторами рассылок

Контекст: сервис рассылок и его эволюция

Мы разрабатывали сервис рассылок для крупного проекта — единую точку отправки email и SMS для всех внутренних сервисов. О самой архитектуре мы подробно рассказывали в статье о сервисе рассылок на Laravel.

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

Этап 1: Mailchimp

Изначально для отправки email мы использовали Mailchimp. Это было удобное и надёжное решение:

• понятный API;

• вебхуки для получения статусов доставки;

• поддержка шаблонов;

• прозрачная аналитика.

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

Этап 2: DashaMail

Мы подключили DashaMail — агрегатор из РФ, который подходил под новые требования.

Что важно: DashaMail сохранил ключевой функционал:

• API-протокол для интеграции;

• вебхуки для получения статусов отправки;

• поддержку шаблонов с передачей дополнительных параметров.

Сервис рассылок продолжил работать без потери функциональности. Клиенты получали письма, поддержка видела статусы, шаблоны работали.

Но параллельно с этим другая внутренняя команда начала разрабатывать собственный внутренний агрегатор рассылок.

Этап 3: Задача от бизнеса — переход на внутренний агрегатор

Когда внутренний агрегатор был готов, бизнес поставил задачу: перевести сервис рассылок с DashaMail на внутренний ресурс.

Логика бизнеса понятна: свой агрегатор — это экономия на внешних подписках. Мы взяли задачу в анализ.

Анализ: что мы выявили

Мы детально изучили внутренний агрегатор и сравнили его с текущим решением. Результаты оказались тревожными.

Проблема 1: Нет API-протокола

Внутренний агрегатор поддерживал только SMTP-протокол, без API.

Что это означало на практике:

• Ряд функционала сервиса рассылок придётся урезать (указание разных отправителей, указание разных адресов для обратной связи, приоритет писем, копии писем).

• Мы не могли гибко управлять отправкой через API.

• Терялась возможность тонкой настройки под разные типы сообщений.

Проблема 2: Нет вебхуков, соответственно статусов

Внутренний агрегатор не отдавал статус отправки через вебхуки.

Что это означало:

• Поддержка не могла определить, ушло письмо или нет.

• Если клиент жаловался, что не получил письмо, — мы не могли это проверить.

• Прозрачность, которую мы выстраивали в сервисе рассылок, исчезала.

Проблема 3: Нет поддержки шаблонов с доп. параметрами

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

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

Проблема 4: Не выдерживает нагрузку

Самое критичное. Мы взяли текущий объём отправок и попробовали прогнать его через внутренний агрегатор на тестовом окружении.

Результат: агрегатор не справлялся с нагрузкой.

Это была не теоретическая проблема, а проверенный факт. Если бы мы перевели клиентские рассылки на внутренний агрегатор, клиенты бизнеса пострадали бы:

• письма доставлялись бы медленно;

• часть писем могла не дойти;

• поддержка не смогла бы разобраться в инцидентах.

Наше решение: отчёт и компромисс

Мы не просто сказали «нет». Мы подготовили детальный отчёт и направили его бизнесу. В отчёте было:

• сравнение функциональности DashaMail и внутреннего агрегатора;

• результаты нагрузочного теста;

• описание рисков для клиентов;

• предложение компромиссного решения.

Предложение

Мы предложили не переводить все рассылки на внутренний агрегатор, а использовать его только для определённых задач:

• Инфраструктурные сообщения — например, письма разработчикам, технические уведомления, внутренние оповещения.

• Клиентские рассылки — оставить на DashaMail или другом внешнем агрегаторе(в будущем), который выдерживает нагрузку и даёт статусы.

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

• сэкономить финансы — часть трафика уходила на внутренний ресурс. При DDos-атаках, нагрузках - это большое количество трафика;

• не рисковать клиентами — критичные рассылки шли через проверенный агрегатор;

• сохранить функциональность — статусы, шаблоны, вебхуки.

Итог: мультиагрегаторный сервис рассылок

После этого анализа и обсуждения с бизнесом сервис рассылок перешёл на мультиагрегаторную модель.

Как это работает теперь:

• Сервис поддерживает несколько агрегаторов одновременно.

• Для каждого типа рассылки можно выбрать подходящий API-отправитель.

• Для каждого шаблона можно настроить свой канал отправки.

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

Что мы вынесли из этой истории

1. Анализ до внедрения — обязателен

Если бы мы просто выполнили задачу бизнеса и перевели всё на внутренний агрегатор, мы бы получили:

• недовольных клиентов;

• заваленную поддержку;

• потерю доверия к сервису.

Анализ и нагрузочное тестирование предотвратили катастрофу.

2. «Нет» — не ответ. Ответ — компромисс

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

3. Иногда внутреннее решение не готово к продакшену

Свой агрегатор — это хорошо. Но если он не выдерживает нагрузку и не даёт нужного функционала, его нельзя ставить на критичные рассылки. Это не «плохо» — это просто не готово для этой задачи.

4. Мультиагрегаторность — это гибкость

Привязка к одному агрегатору — это риск. Если он падает или меняет условия, страдает бизнес. Несколько агрегаторов дают резервирование и гибкость.

Заключение

Эта история — про то, что техническое решение нельзя принимать только на основе экономии. Иногда экономия на агрегаторе оборачивается потерями на клиентах.

Мы отстояли клиентов бизнеса, предложив компромисс. И в итоге получили сервис, который стал гибче и надёжнее, чем был до этой задачи.