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

Задача

Пользователи CRM-системы могут отправлять как единичные СМС, так и массовые СМС- и email-рассылки.
В рамках интеграции необходимо было реализовать их отправку через внешний сервис-провайдер.

Архитектура

Для решения задачи был спроектирован отдельный микросервис. В его интерфейсе пользователь задаёт параметры, необходимые для отправки СМС и email-рассылок.

При поступлении задачи микросервис отправляет её в RabbitMQ. Для единичных СМС и массовых рассылок предусмотрены отдельные очереди.

Алгоритмы отправки сообщений и массовых рассылок

Отправка единичных сообщений через внешний провайдер

  1. Микросервис подписывается на вебхуки метода единичных СМС-сообщений

  2. При создании СМС в интерфейсе CRM микросервис получает вебхук и инициирует отправку сообщения через API провайдера

  3. Если вебхук не дошёл - микросервис каждый час (условно) по CRON проверяет наличие новых сообщений в CRM

  4. После успешной отправки СМС микросервис каждые 5 минут запрашивает статус у провайдера и обновляет его в CRM. Проверка продолжается, пока статус не станет финальным

Схема отправки единичного сообщения
Схема отправки единичного сообщения

Отправка массовых рассылок через внешний провайдер

  1. Микросервис подписывается на вебхуки методов, отвечающих за СМС- и email-рассылки

  2. При создании рассылки в интерфейсе CRM микросервис получает вебхук и инициирует отправку через API провайдера
    Важно: перед отправкой необходимо создать или обновить список контактов в сервисе провайдера

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

  4. Обновление статуса происходит каждые 5 минут до получения финального результата

Схема отправки СМС- или email-рассылки
Схема отправки СМС- или email-рассылки

Заключение

Интеграция с внешним провайдером рассылок - задача, которая требует надёжной архитектуры. Мы выбрали микросервисный подход, добавили резервный канал через CRON и разделили потоки через очереди. Это позволило нам не потерять ни одно сообщение и выдержать пиковые нагрузки.

Ключевые выводы:

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

  • добавлять резервные механизмы;

  • разделять разные типы трафика.

Эти принципы применимы не только к интеграциям, связанным с рассылками, но и к любым интеграциям с внешними сервисами.