В этой статье я делюсь практическим опытом проектирования интеграционного решения для CRM-системы.
Статья будет полезна системным аналитикам и разработчикам, которые проектируют асинхронные интеграции с внешними сервисами и хотят избежать потери данных.
Задача
Пользователи CRM-системы могут отправлять как единичные СМС, так и массовые СМС- и email-рассылки.
В рамках интеграции необходимо было реализовать их отправку через внешний сервис-провайдер.
Архитектура
Для решения задачи был спроектирован отдельный микросервис. В его интерфейсе пользователь задаёт параметры, необходимые для отправки СМС и email-рассылок.
При поступлении задачи микросервис отправляет её в RabbitMQ. Для единичных СМС и массовых рассылок предусмотрены отдельные очереди.
Алгоритмы отправки сообщений и массовых рассылок
Отправка единичных сообщений через внешний провайдер
Микросервис подписывается на вебхуки метода единичных СМС-сообщений
При создании СМС в интерфейсе CRM микросервис получает вебхук и инициирует отправку сообщения через API провайдера
Если вебхук не дошёл - микросервис каждый час (условно) по CRON проверяет наличие новых сообщений в CRM
После успешной отправки СМС микросервис каждые 5 минут запрашивает статус у провайдера и обновляет его в CRM. Проверка продолжается, пока статус не станет финальным
Отправка массовых рассылок через внешний провайдер
Микросервис подписывается на вебхуки методов, отвечающих за СМС- и email-рассылки
При создании рассылки в интерфейсе CRM микросервис получает вебхук и инициирует отправку через API провайдера
Важно: перед отправкой необходимо создать или обновить список контактов в сервисе провайдераПосле успешного создания рассылки микросервис получает сведения о доставке и обновляет их в CRM
Обновление статуса происходит каждые 5 минут до получения финального результата
Заключение
Интеграция с внешним провайдером рассылок - задача, которая требует надёжной архитектуры. Мы выбрали микросервисный подход, добавили резервный канал через CRON и разделили потоки через очереди. Это позволило нам не потерять ни одно сообщение и выдержать пиковые нагрузки.
Ключевые выводы:
не полагаться только на вебхуки;
добавлять резервные механизмы;
разделять разные типы трафика.
Эти принципы применимы не только к интеграциям, связанным с рассылками, но и к любым интеграциям с внешними сервисами.