Архитектура

Event bus для оператора: общий нерв вместо point-to-point интеграций

Каждая новая интеграция в point-to-point модели — boilerplate и debt. Event bus делает события first-class объектом архитектуры. Topics, contracts, владельцы.

Обсудить задачу

Зачем оператору event-driven core

В типичном операторе 30-50 систем. В point-to-point модели каждая новая интеграция — отдельный коннектор, со своим контрактом, своим способом восстановления после падения, своим owner. Через 5 лет интеграционный layer становится дороже, чем core-системы.

Event bus превращает события (активация, платёж, пополнение, инцидент, изменение тарифа) в first-class объект архитектуры. Producer публикует событие в topic — consumer’ы (любое количество) подписываются и реагируют.

Это не «технология ради технологии». Это операционная необходимость для оператора, у которого больше 20 потребителей одних и тех же событий.

Структурные элементы

Topics. Логические каналы событий. Принципы именования: {domain}.{entity}.{action} — billing.payment.received, network.session.started, crm.case.created.

Schemas / contracts. Каждое событие имеет схему (Avro / JSON Schema / Protobuf). Контракт — обязательство producer’а: формат не меняется без backward compatibility или major version bump.

Schema registry. Централизованное хранилище схем с историей. Consumer’ы валидируют события против registry.

Producer guarantees. At-least-once delivery, идемпотентные событийные ID, ordering в рамках partition.

Consumer patterns. Каждый consumer держит свой offset, может re-process от нужной точки. Slow consumer не блокирует fast consumer.

Dead letter queue. Сообщения, которые consumer не смог обработать, идут в DLQ для разбора, а не теряются.

Observability. Метрики по топикам: throughput, lag, error rate. Trace events через цепочку consumer’ов.

Где обычно ломается

Bus есть, контрактов нет. Producer меняет формат события, consumer’ы ломаются молча. Через месяц никто не знает, какие данные actual.

Topic naming chaos. Каждая команда называет topics по-своему. Через год — невозможно понять, кто что публикует и кто слушает.

Owner topic’а отсутствует. При изменении схемы непонятно, с кем согласовывать. Изменения происходят без согласования.

Bus сделан под одно решение (например, для CDP), но потом в него начинают сливать всё подряд. Capacity не пересчитан, latency растёт.

Для критичных flow используется bus без проверки on-time delivery — например, биллинг публикует событие платежа, но consumer (CRM) обрабатывает с задержкой 5 минут, и оператор contact center видит «не оплачено» уже после оплаты.

Идемпотентность не enforced. При retry consumer создаёт duplicate, и downstream-данные расходятся.

Governance модель

Bus — общий ресурс. Без governance он деградирует за 12-18 месяцев.

Минимум:

Каждый topic имеет owner (data steward / domain owner).
Schema changes требуют PR review с обязательным acknowledge от consumer’ов.
Backward compatibility — обязательное правило для public topics.
Operating routine — еженедельный обзор top consumers / producers, lag, error rates.

Без owner’а bus превращается в свалку.

Что не event’и

Не всё надо публиковать в bus. Запросы (request/response) — это не event. Их место — API Gateway, не event bus. Большие файлы (CDR-batch на гигабайты) — не event, это файловый поток.

Event — нечто, произошедшее с бизнес-сущностью, которое может интересовать несколько consumer’ов. Если нет минимум двух consumer’ов или потенциала на них — это просто RPC-вызов.

Как SamaraliSoft подключается

Event-Driven Blueprint — 6-8 недель. Inventory текущих integrations, дизайн topic taxonomy, governance framework, technology choice (Kafka / RabbitMQ / managed cloud), pilot scope — обычно один domain (биллинг или network), интеграция 3-5 consumer’ов.