🏛️
Section 10.4
Event-Driven Architecture in Telco
Event-driven patterns, saga orchestration, and CQRS in BSS/OSS context.
In a modular BSS/OSS, components must communicate. While synchronous APIs (REST) are essential for queries and commands, event-driven architecture is what makes a distributed BSS/OSS truly resilient, scalable, and loosely coupled. Telco operations are inherently asynchronous — an order triggers a cascade of fulfilment steps that may take minutes, hours, or days.
Event Producers
Product Catalog
TMF620
COM
TMF622
SOM
TMF641
ROM
TMF652
OfferingChanged
OrderCompleted
ServiceActivated
ResourceAllocated
Event BusKafka / TMF688
bss.catalog.eventsbss.ordering.eventsoss.service.eventsoss.resource.events
Event Consumers (Subscribe Independently)
Billing
Charges on order
Product Inventory
Updates subs
SLM
Tracks CFS/RFS
Notifications
SMS / Email / Push
Analytics
BI / Reporting
Saga Pattern — Distributed Transaction Coordination
ChoreographyEvent-driven chain (simple flows)
OrderCreated→ServiceActivated→BillingStarted
OrchestrationSOM coordinates (complex fulfilment)
SOM→Allocate→Activate→Inventory→Notify COM
Why Event-Driven Matters
Synchronous vs Event-Driven
| Scenario | Synchronous (REST) | Event-Driven |
|---|---|---|
| Service activation | SOM calls ROM synchronously and blocks. If ROM is slow or down, SOM is stuck. | SOM emits ServiceOrderCreated. ROM picks it up when ready. No blocking. |
| Billing notification | Billing must call CRM, self-service, and notifications sequentially. | Billing emits BillGeneratedEvent. Each consumer subscribes independently. |
| Fault propagation | If billing is down, anything calling billing fails. Cascading failures. | Events are queued. When billing recovers, it processes the backlog. |
| Adding consumers | Each new system needs a new API call added to the producer. | New consumers subscribe to existing events. No changes to the publisher. |
The Key Insight
Event-driven architecture changes "who knows about whom." The order service just publishes events — it does not know or care who listens. This inversion of dependencies is what makes the system truly modular.
TMF Event Management
TMF Hub/Listener Pattern
Every TMF Open API that supports events defines: (1) a Hub where consumers register interest in event types, and (2) a Listener callback endpoint that receives notifications. This is essentially a standardised webhook pattern. For high-volume event streams, production deployments typically use Kafka or RabbitMQ underneath, exposing Hub/Listener as a compatibility layer on top.
Standard TMF event types include: CreateEvent (entity created), StateChangeEvent (lifecycle transition), AttributeValueChangeEvent (significant attribute changed), and DeleteEvent (entity retired).
The Saga Pattern
In a monolithic BSS, a single database transaction spans ordering, billing, and inventory. In a modular architecture, this is impossible. The Saga pattern manages distributed transactions by breaking them into a sequence of local transactions, each publishing events that trigger the next step. If any step fails, compensating transactions undo preceding changes.
Choreography vs Orchestration Sagas
| Aspect | Choreography | Orchestration |
|---|---|---|
| Coordination | Decentralised — each service reacts to events | Centralised — orchestrator directs each step |
| Visibility | Hard to see the full flow — events scattered across services | Easy — orchestrator represents the complete workflow |
| Error handling | Complex — compensating events propagate back through the chain | Simpler — orchestrator manages compensation centrally |
| Telco fit | Simple flows (notification chains, billing triggers) | Complex fulfilment (order activation, service modification) |
Recommendation
Most telco deployments use orchestration sagas for order fulfilment (SOM as orchestrator) and choreography sagas for cross-domain notifications (billing, CRM updates). This hybrid gives clear control over the critical path while keeping peripheral integrations loosely coupled.
Essential Implementation Patterns
Patterns Every Telco Needs
| Pattern | What It Solves | How It Works |
|---|---|---|
| Transactional Outbox | Prevents DB updated but event lost (or vice versa) | Write events to an outbox table in the same DB transaction. A relay process publishes to the broker. |
| Idempotent Consumers | Handles duplicate event delivery safely | Use event IDs to detect duplicates. Make state transitions idempotent (setting "completed" when already "completed" is a no-op). |
| Dead Letter Queue | Prevents unprocessable events from blocking the pipeline | After N retries with backoff, move to DLQ. Alert ops. Replay after root cause fix. |
| Correlation ID | Traces a business operation across all events and services | Generate unique ID at entry (COM). Propagate in every event header. All logs include it. |
Compensating Transactions Are Not Perfect Undo
Compensation creates a new action that logically reverses the effect. A cancelled order is not the same as one that never existed. If a customer was charged before the failure, the compensation is a credit, not a deletion. When a compensating transaction itself fails after retries, it must escalate to a human operator — infinite retry is not a strategy.
Section 10.4 Key Takeaways
- Event-driven architecture makes BSS/OSS truly modular — publishers do not know about consumers
- TMF Hub/Listener is the standardised pattern; production systems use Kafka or RabbitMQ underneath
- Saga pattern manages distributed transactions: choreography for simple chains, orchestration for complex fulfilment
- Use at-least-once delivery with idempotent consumers — the practical standard for telco BSS/OSS
- Transactional outbox prevents data/event inconsistency; dead letter queues prevent event loss
- Correlation ID propagation across all events is mandatory for operational traceability