Интеграция с сервисом рассылок: RabbitMQ, вебхуки и CRON

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

Задача

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

Архитектура

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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