Event bus for an operator: a shared nerve instead of point-to-point integrations

Why an operator needs an event-driven core

A typical operator has 30-50 systems. In a point-to-point model every new integration is a separate connector, with its own contract, its own recovery mechanism, its own owner. After five years the integration layer becomes more expensive than the core systems.

Event bus turns events (activation, payment, top-up, incident, tariff change) into first-class architecture objects. Producer publishes an event to a topic — consumers (any number) subscribe and react.

This is not “technology for technology’s sake”. This is an operating necessity for an operator with more than 20 consumers of the same events.

Structural elements

Topics. Logical channels of events. Naming principle: {domain}.{entity}.{action} — billing.payment.received, network.session.started, crm.case.created.

Schemas / contracts. Each event has a schema (Avro / JSON Schema / Protobuf). The contract is the producer’s obligation: the format does not change without backward compatibility or a major version bump.

Schema registry. Centralised schema store with history. Consumers validate events against the registry.

Producer guarantees. At-least-once delivery, idempotent event IDs, ordering within a partition.

Consumer patterns. Each consumer holds its own offset and can re-process from any point. A slow consumer does not block a fast one.

Dead letter queue. Messages a consumer fails to process go to DLQ for analysis, not lost.

Observability. Metrics per topic: throughput, lag, error rate. Trace events through the consumer chain.

Where it usually breaks

There is a bus but no contracts. Producer changes the event format, consumers break silently. A month later nobody knows which data is actual.

Topic naming chaos. Each team names topics in its own way. A year later — impossible to understand who publishes what and who listens.

Topic owner is missing. When a schema changes, it is unclear who to coordinate with. Changes happen without coordination.

The bus was built for one solution (for example, CDP), but then everything starts being dumped into it. Capacity is not recalculated, latency grows.

For critical flows the bus is used without on-time delivery checks — for example, billing publishes a payment event, but the consumer (CRM) processes with 5-minute delay, and the contact-centre operator sees “not paid” after payment was made.

Idempotency is not enforced. On retry the consumer creates a duplicate, and downstream data diverges.

Governance model

The bus is a shared resource. Without governance it degrades within 12-18 months.

Minimum:

• Each topic has an owner (data steward / domain owner).
• Schema changes require PR review with mandatory acknowledgement from consumers.
• Backward compatibility — a mandatory rule for public topics.
• Operating routine — weekly review of top consumers / producers, lag, error rates.

Without an owner the bus turns into a junkyard.

What is not an event

Not everything needs to be published to the bus. Request/response is not an event. Its place is the API Gateway, not the event bus. Large files (multi-GB CDR batches) are not events — they are a file stream.

An event is something that happened to a business entity that may be of interest to several consumers. If there are not at least two consumers or potential for them — this is just an RPC call.

How SamaraliSoft engages

Event-Driven Blueprint — 6-8 weeks. Inventory of current integrations, topic taxonomy design, governance framework, technology choice (Kafka / RabbitMQ / managed cloud), pilot scope — usually one domain (billing or network), integration of 3-5 consumers.

Related

• /en/architecture/telecom-cdp-architecture/ — CDP as event consumer
• /en/architecture/telecom-realtime-decisioning-architecture/ — decisioning on events
• /en/insights/telecom-integration-debt/ — integration debt
• /en/architecture/telecom-partner-api-platform/ — partner API