Платформа событий и веб-хуков

Eventing (modules/eventing, LIVE) превращает внутрипроцессную шину событий движка во внешнюю поверхность подписок. Тогда как сама шина работает по принципу «не более одного раза» и теряет события при остановке, этот модуль является границей устойчивости: как только событие зафиксировано в транзакции захвата, его доставка становится устойчивой и пригодной для аудита. Его маршруты монтируются под /v1/m/eventing/.

Редакция: подписки на подписанные webhook доступны в Community. SIEM-приёмники (с заданным sink_kind) требуют Business: сервер Community отвечает 501 business_required на создание или обновление, которое его содержит. Приёмник, сохранённый раньше, ничего не доставляет; обновление без него отключает или очищает приёмник подписки, а DELETE удаляет подписку.

На что вы подписываетесь

Подписка фиксирует нужные ей типы событий, необязательный фильтр по источнику, URL конечной точки потребителя, роль, под которой авторизуются её доставки, и сгенерированный сервером секрет подписи HMAC (возвращается ровно один раз, затем хранится только через стык запечатанного хранения at-rest). Доступные для подписки типы берутся из типизированного каталога — GET /event-types возвращает каждый тип с его уровнем стабильности и разрешением, которое его ограничивает. Управление подписками является привилегированным и проходит аудит: создание/обновление/ротация секрета относятся к уровню записи (write-tier); удаление, воспроизведение, повторная доставка и тестовые доставки — к уровню администратора (admin-tier).

Гарантии доставки

Доставка работает по принципу «не менее одного раза» с ключами идемпотентности потребителя — доставка «ровно один раз» была отвергнута как ложное обещание. Каждое захваченное событие становится одной устойчивой строкой доставки на каждую соответствующую подписку, помещённой в очередь в той же транзакции. Рабочие процессы захватывают строки по оптимистичной версии (безопасно при HA), отправляют POST с подписанным конвертом события и либо подтверждают (2xx), либо планируют следующую попытку:

Повторы с экспоненциальной задержкой — 408/425/429/5xx и сетевые ошибки повторяются по графику задержки; любой другой статус является терминальным. Перенаправления никогда не отслеживаются.
Очередь недоставленных сообщений (dead-letter) — исчерпавшие попытки доставки попадают в статус dead; статус denied фиксирует отказ RBAC по конкретному событию.
Воспроизведение по курсору — монотонная последовательность на каждого арендатора (выделяемая из строки курсора, а не из max(seq)) позволяет воспроизводить с заданной точки устойчивого журнала, ограниченного окном хранения.

Каждая попытка несёт подпись HMAC-SHA256 с меткой времени в стиле Stripe плюс стабильный идентификатор события в качестве ключа идемпотентности. Перед каждой попыткой диспетчер прогоняет полный конвейер RBAC+ABAC с отказом по умолчанию (deny-closed) против роли подписки, поэтому исходящее событие фильтруется ровно так же, как фильтровалось бы живое чтение.

Ограниченный контекст, прямо заявленный

Внутрипроцессная шина работает по принципу «не более одного раза» с потерей при остановке; устойчивость начинается с транзакции захвата, а не с публикации. События, опубликованные, когда им не соответствует ни одна включённая подписка, не захватываются (экономия хранилища), поэтому воспроизведение доходит назад только до момента захвата.
Многоузловой мост NATS честно работает по принципу «не более одного раза» — эта платформа является устойчивым слоем над ним, а не гарантией для самой распределённой шины.
Это обращённая к интеграторам поверхность; notify остаётся обращённым к операторам маршрутизатором оповещений. См. честность и ограничения для соглашений live / on-demand / deny-closed.

Связанное

Пересылка в SIEM — отправляет запечатанный audit ledger и находки в башни SIEM; построена непосредственно на этой платформе.
Notify — обращённый к операторам маршрутизатор оповещений к заранее подготовленным назначениям.
Справочник по событиям — словарь событий, на которые вы подписываетесь, и форма доставляемого конверта.