Event
Один входящий запрос с данными события и результатом проверки. Принятое событие запускает подбор получателей; дубликат или отказ — нет.
Сервис обработки входящих событий и веерной отправки получателям
Принимает HTTP-события, выбирает получателей по настраиваемым правилам, создаёт отдельную отправку для каждого совпадения и хранит историю доставки.
О проекте
Что делает сервис
Сервис принимает HTTP-события от рекламных, аналитических и продуктовых систем и проверяет ключ источника и обязательные поля. Для каждого бренда он находит включённые Watcher — настройки маршрутов — и проверяет связанные с ними Rule: условия для событий, данные получателя и лимиты отправки. В условии можно использовать настроенный макрос: выбрать поле события, преобразовать его и передать результат правилу. Для каждого совпадения создаётся отдельный HTTP-запрос. Повторное событие с тем же ключом в течение 24 часов считается дубликатом. Сервис использует две базы PostgreSQL: одна хранит настройки платформ, брендов, источников, Watcher, Rule и макросов; вторая транзакционно хранит принятые события и очереди обработки и отправки. В ClickHouse событие копируется после приёма, решения маршрутизации — после выбора получателей, а отправки и попытки — после получения итогового статуса. Записи PostgreSQL удаляются только после проверки копии в ClickHouse.
Одно событие нужно отправить в несколько систем, у каждой — свои условия и формат запроса. Сервис выбирает получателей, повторяет временно неудачные отправки и сохраняет результаты для операторов.
Кто пользуется
Команды, связывающие рекламные, аналитические и продуктовые системы событиями; сотрудники операций, которые настраивают правила и разбирают ошибки доставки.
Что на входе
- HTTP-запрос с ключом источника и полями события.
- Настройки платформы, бренда и источника.
- Условия Watcher, Rules, настроенные макросы и URL получателей.
Что на выходе
- Результат приёма: событие принято, распознано как дубликат или отклонено.
- Отдельный исходящий запрос и история статусов для каждого подошедшего получателя.
- История в ClickHouse: приём событий, решения маршрутизации и завершённые доставки.
Правила обработки событий
- Для каждого источника проверяются платформа, бренд и ключ.
- Принятое событие проверяется на дубликат в течение 24 часов перед подбором получателей.
- Watcher, Rule и настроенные макросы определяют, кому и с какими параметрами отправить событие.
- События, решения маршрутизации и итоговые результаты доставки синхронизируются в ClickHouse на разных этапах.
01 / Архитектура
Основные сущности
Watcher
Включённая настройка получателя для бренда. Её условия определяют, нужно ли рассматривать событие для отправки.
Rule
Задаёт условия события, поля запроса и лимиты отправки для маршрута. При совпадении для получателя создаётся отдельный Postback.
Macro
Оператор выбирает поле payload, поддерживаемую функцию преобразования текста и её параметры. Полученное значение можно использовать в условии Rule и проверить до применения правила.
Postback / delivery attempt
Postback хранит подготовленный запрос для одного получателя; задача доставки — попытки, ответы, время повтора и итоговый статус.
От одного входящего события к отдельным отправкам получателям
Четыре этапа показывают, что хранится, как применяются правила, когда повторяется отправка и в какой момент данные попадают в ClickHouse.
Принять и убрать дубликаты
Каждый запрос сохраняется; маршрутизация запускается только для первого принятого события.
Внешняя платформа
Отправляет событие с ключом платформы и данными события.
Проверить источник
Сверяет платформу и бренд с настройками, проверяет ключ и обязательные поля.
Записать событие и решить вопрос с дубликатом
Одна транзакция с advisory lock проверяет ключ события за последние 24 часа и записывает событие вместе с решением о приёме.
Отдельная административная PostgreSQL: платформы, бренды, ключи источников, Watcher, Rule и макросы.
Выбрать маршруты и подготовить отправки
Fan-out worker превращает принятое событие в отдельную задачу для каждого подходящего получателя.
Захватить событие
Worker захватывает событие через SKIP LOCKED; параллельные worker могут брать другие события.
Найти активные Watcher
Связь с брендом определяет, какие Watcher должны проверить событие.
Проверить условия
Rule проверяет событие и лимиты отправки. Макрос может взять поле payload, преобразовать его настроенной функцией по разделителю и передать результат в условие правила.
Создать запись для каждого совпадения
Для каждого подошедшего получателя создаётся отдельный запрос. Решение и причина записываются вместе с ним.
Отправить, сохранить ответ, при необходимости повторить
HTTP-вызов выполняется вне транзакции БД; lease определяет, какой worker может записать результат.
Временно зарезервировать отправку
Worker временно резервирует задачу. Если резерв истёк, старый worker не сможет перезаписать результат новой попытки.
Вызвать получателя
Отправить запрос, собранный по правилу, и сохранить статус и ответ этой попытки.
Ответ получателя2xxОтметить доставленным 429, 5xx, network errorНазначить повтор с увеличением задержки Постоянная ошибка или исчерпан лимит попытокЗавершить с ошибкой и сохранить историю попыток
Архивировать и очистить очередь
Каждая запись синхронизируется, когда её состояние готово; из PostgreSQL она удаляется только после проверки копии в ClickHouse.
ClickHouse
Версионная история событий, решений и доставок для фильтров и отчётов.
Сверить перед удалением
Перед удалением записи PostgreSQL задача очистки проверяет, что соответствующая строка есть в ClickHouse.
02 / Архитектура системы
Основные части и их роль
Проверить источник
Сверить платформу, бренд, ключ источника и обязательные поля события.
Как устроено
API сохраняет результат приёма в PostgreSQL для обработки. Настройки источника и бренда находятся в отдельной административной PostgreSQL базе.
Записать и убрать дубликаты
Сохранить каждый запрос. Если то же принятое событие пришло повторно в течение 24 часов, отметить дубликат и не запускать маршрутизацию ещё раз.
Как устроено
Транзакционная advisory-блокировка защищает проверку ключа идемпотентности при записи события.
Выбрать получателей
Проверить событие и бренд по каждому включённому Watcher и его Rules.
Как устроено
Настроенный макрос берёт поле payload, применяет поддерживаемое преобразование текста и передаёт результат в условие Rule. Совпавшее правило собирает запрос получателя и проверяет лимиты.
Создать отправку для каждого совпадения
Создать отдельный Postback для каждого получателя, у которого совпало Rule.
Как устроено
Worker захватывает события через SKIP LOCKED. Postback, решения по маршрутам и завершение обработки события сохраняются одной транзакцией.
Отправить запрос
Захватить ожидающий Postback и вызвать URL получателя.
Как устроено
HTTP-вызов выполняется вне транзакции БД. Lease-токен не даёт просроченному worker перезаписать более новый результат.
Сохранить результат или назначить повтор
Сохранить ответ и номер попытки. Повторить временную ошибку HTTP 429, 5xx или сети после задержки.
Как устроено
Успешная отправка, постоянная ошибка и исчерпание повторов получают итоговый статус и историю попыток. Если worker остановится после отправки, но до записи ответа, сервис может повторить запрос.
Архивировать по этапам обработки
Скопировать событие после приёма, решения Watcher/Rule после маршрутизации, а Postback с попытками — после завершения доставки.
Как устроено
Синхронизация выполняется асинхронно и повторяет неудачные копирования. Worker отмечает строки PostgreSQL после успешного копирования; очистка сначала проверяет соответствующую запись в ClickHouse и только затем удаляет оперативные данные.
03 / Детали реализации
Инженерные решения
PostgreSQL хранит текущую работу
Транзакции PostgreSQL защищают принятые события, решения маршрутизации, задачи отправки и их текущее состояние.
Для HTTP-отправок используются lease
Worker резервирует отправку, выполняет сетевой вызов вне транзакции и сохраняет ответ, только пока владеет lease.
ClickHouse хранит историю обработки
События, решения правил и попытки доставки копируются по достижении своего этапа синхронизации; строки PostgreSQL очищаются только после появления копии.
Разработка приложений для бизнеса
Есть задача для разработки?
Расскажите, что должно делать приложение, как команда работает сейчас и какие требования или сроки важно учесть.