Ранее в этом году наша компания выбрала Hubspot Enterprise в качестве платформы для консолидации наших систем публикации контента, входящего маркетинга, CRM и продаж. Мы очень довольны этим решением и в последние месяцы начали более глубокую интеграцию с устаревшими системами в рамках подготовки к дальнейшей консолидации и выводу из эксплуатации. Однако, используя рабочие процессы и веб-перехватчики, мы недавно обнаружили проблемы с повторяющимися записями в устаревшей базе данных, и наша команда по продажам по телефону вручную устраняет дубликаты записей.
Инстинктивной реакцией было то, что что-то не так с веб-формами, и нам нужно было запретить пользователям дважды щелкать кнопки отправки. Однако после дальнейших исследований мы обнаружили, что Hubspot повторно отправляет веб-хуки, используя экспоненциальную отсрочку, что приводит к дублированию записей. Один из наших инженеров наткнулся на эту дискуссию на форуме, которая ускользнула от проблемы; веб-перехватчики имеют короткий тайм-аут, и если ваш сервис превышает его, он считает попытку неудачной и повторяет попытку, используя экспоненциальную отсрочку.
Мы уже создали «прокси» микросервиса для Hubspot, который обеспечивает взаимодействие API и веб-перехватчиков между другими нашими системами, но взаимодействия были по большей части синхронными, учитывая, что устаревшие приложения были приложениями .NET и PHP с SQL Server и серверными частями MySQL. соответственно. Нам пришлось дождаться ответа этих приложений, прежде чем зарегистрировать попытку в Elasticsearch, нашем новом центральном хранилище аналитики и мониторинга в реальном времени. К сожалению, некоторые из этих запросов могут превышать 2-секундный тайм-аут для гео-запросов, что приводит к дублированию данных.
Использование Google PubSub и облачных функций для асинхронности
Чтобы решить эту проблему, мы решили разбить синхронные последовательные операции на асинхронные операции. «Прокси» просто принимал веб-хуки от Hubspot и немедленно публиковал сообщение в теме PubSub. Облачная функция с темой A в качестве триггера затем отправит запрос к устаревшему API и будет ждать ответа. Затем эта функция опубликует ответ в другой теме PubSub. Другая облачная функция с темой B в качестве триггера продолжит сохранение данных в Elasticsearch.
Я рад сообщить, что пересмотренный дизайн отлично сработал, устранил риск тайм-аута (при условии, что публикация в PubSub не вызывает проблем) и подготовила систему к масштабированию в будущем. Более того, нашей команде по продажам по телефону больше не нужно вручную удалять дубликаты записей, и мы снизили нагрузку на системы Hubspot (мы надеемся, что они смогут присылать нам гораздо больше потенциальных клиентов).
