Как организовывать событийную архитектуру

Как организовывать событийную архитектуру

Недавно я задавал задачку, как организовать выгрузку событий для маркетологов и продактов, которым надо следить за метриками, строить воронки и вообще всячески увеличивать конверсии и прибыль. Было много разных ответов и в целом все сводилось к тому, что мы куда то в шину кидаем сообщения, дальше их выгребаем и все равно рассылаем ручками по нужным системам (внешним сервисам). Ну или у вас поток событий настолько большой, что вы просто складываете это куда-то к себе в кликхаус и уже на эти данные натравливаете аналитические тулы типа суперсета или метабейза.

Несмотря на универсальность истории с шиной, конкретно отправка таких событий это довольно устоявшаяся концепция, для которой есть стандартизированное решение. Примерно как все начинают кричать про outbox, когда речь идет про отправку, мне хочется кричать CDP, когда речь идет про продуктовую и маркетинговую аналитику. В общем рассказываю.

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

Доменные события

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

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

```ruby

# выполнили регистрацию и делаем событие

data = { user_id: user.id }

event = UserSignedUpEvent.new(data:)

EventSender.publish_event(event)

```

Событие вызывается сразу синхронно (а еще складывается в базу) и дальше отрабатывают связанные с ним обработчики. Это все настраивается во время сетапа. Теперь мы можем создать универсальные обработчики под свои задачи. Например реализовать отправку аналитики. Выглядеть это будет так, какая-то функция, которая принимает на вход объект события. Мы смотрим тип события и на основе этого выполняем нужную логику.

Отправка событий

И так у нас есть обработчик событий (доменных) для аналитики, который выполняется синхронно, смотрит на события и в зависимости от их типа решает что делать. Для начала нам надо сделать процесс отправки асинхронным. Это два типовых варианта, либо асинхронные джобы (о которых был недавний пост), либо очереди/стриминг с отдельным приложением (микросервисом?), которое непосредственно шлет во внешние системы и складывает в базу если надо. В целом это не принципиально и обычно вписывается в существующую инфраструктуру.

А вот сама отправка это интересно. Если действовать в лоб, то мы бы взяли sdk сервисов, которые нам нужны, например posthog для продуктовой аналитики, mailchimp для crm-маркетинга и т.п. Больше сервисов, больше интеграций, больше трансформаций данных под конкретные системы с их собственными принципами работы.

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

Ссылки: Телеграм | Youtube | VK

p.s. Не хватило места, последнее разберу отдельным постом