Event-driven telecom: why nightly batch loads no longer fit the 2026 business

Where the nightly load came from

In the mid-2010s telecom operations architecture in the region was built like this. Billing, CRM, analytics, marketing, retention — each system had its own database. The link between them was nightly loads. Billing dropped yesterday’s data into the DWH in the morning, marketing saw fresh numbers next day, retention 24-48 hours later.

This worked for the tasks of the time. Most business decisions were taken on monthly cycles. A campaign was planned a week ahead, a segment was extracted from the DWH a day before launch — that was enough.

By the late 2020s the picture changed. The decisions required in 2026 operate on different timeframes:

Anti-fraud. A SIM swap has to be detected in the moment, not 24 hours later — by then the fraudster has moved the money.

Anti-scam. A fraud-call pattern has to be recognised within seconds, not hours — otherwise blocking does not help.

Network compensation. If a customer is having quality issues now, the signal to the communication has to arrive within minutes, not next day after the incident is over.

Real-time NBA. When the customer is in the app, the recommendation has to take their action a second ago into account, not yesterday’s batch.

Trust signals to partners. The bank partner asks for a SIM-status signal — needs it in real time, otherwise the banking transaction is already through.

None of this is delivered on batch architecture. An event-driven model is needed.

What event-driven actually means

Event-driven architecture does not mean “everything in real time”. It means:

Every meaningful event in the operator’s systems is published to a shared event bus the moment it happens. SIM activated — event. Payment made — event. Tariff change — event. Complaint logged — event. Network incident at a location — event. All published in the moment.

Any downstream system can subscribe to events relevant to it and react. Anti-fraud subscribes to SIM/device events. Marketing subscribes to usage anomalies. Retention subscribes to churn signals. CRM subscribes to customer interactions.

The reaction can be real-time or delayed — defined by each consumer’s requirement. Anti-fraud — milliseconds. Marketing — minutes. Reporting — hours. Not all real-time, but all event-aware.

Each event is an immutable record with timestamp, source, payload, correlation ID. This enables audit, replay, late processing.

Where building usually starts

Not “convert everything to event-driven at once”. The path is 2-3 years. Phased.

Months 1-6. Foundation. Event bus as an infrastructure component. Standards for events (schema, format, guarantees). Identification of 5-7 most critical event types as a starter.

Months 7-12. First producers. SIM/device events from core systems. Customer interaction events from CRM. Billing events. Often major work — legacy systems either get modified or wrapped in adapters. Both are imperfect.

Months 13-18. First consumers. Anti-fraud subscribes to SIM events. Marketing subscribes to usage events. NBA subscribes to customer behaviour events. Real-time use cases start working.

Months 19-24. Expansion and operating model. Additional event types. SLA discipline. Event flow monitoring. Replay capability for fault tolerance.

Months 25-36. Sustainable. Most operations integrated through events, batch loads only for historical reports.

By three years in the operator has a working event-driven foundation. Not a single project — a rebuild of how operations work.

What often becomes a barrier

Legacy systems that do not support event publishing. Old billing was written without the notion of events. To make it publish events you either patch the biller (often vendors do not allow it) or place external adapters that read biller logs and convert into events. Both are imperfect.

Vendor lock-in. Vendors of core systems may not be cooperative on event integration. Some require their own proprietary integration layer instead of a standard event bus.

Operations discipline. Event-driven requires a different operations mindset. If the team is used to “the morning load is there — the system is working”, moving to event-flow monitoring needs training.

Cost. Event bus infrastructure plus core modernisation plus building adapters plus training — a serious investment. The board often demands ROI that is not obvious until the first real-time use cases are live.

Skills. Event-driven engineering is a separate skill set. Local talent in the region is limited. Either invest in training or hire at a premium.

What often goes wrong

Building the event bus without commitment to event-driven operations. The bus exists, but teams keep working through batch — the bus is underused.

Big-bang migration. Rarely works. Phased by event type and consumer type is the only stable path.

A vendor promises “event-driven out of the box” but actually delivers batch with short cycles. Distinction critical — ask for technical detail, not a presentation.

Event schema without discipline. Each team creates its own events with its own schema, with no common standard. A year later — hundreds of event types, no cross-system coherence.

No replay capability. Events flow in real time, but if a consumer fails, events are lost. Without a durable event log, fault tolerance does not work.

When event-driven is not a priority

If the organisation is in an acute phase of basic operational stability (billing unreliable, reconciliation poor), focus on core stability matters more.

If real-time use cases are not critical yet (anti-fraud manageable, marketing on monthly cycle works acceptably), event-driven build delivers little immediate ROI.

If the budget is constrained on an 18-24 month investment without visible first-year ROI, the build will be cancelled in phase 1.

If internal skills are weak and hiring is impossible, event-driven becomes expensive vendor consultancy.

If C-level is not committed to operations transformation, the build stays technological without operational change.

Discussion points for the committee

Which 3-5 use cases require real-time right now or in the next 18 months? That is the business case.

What is the current architecture of core systems — do they support event publishing? What is the gap?

Who owns architecture transformation? If just IT — projects do not touch operations.

What 24-36 month investment commit is needed and is it there?

What is the cooperation level from core-system vendors? If incompatible — that is the key block.

How SamaraliSoft can help

Event-Driven Architecture Transformation — analysis of current architecture, mapping business requirements to event-driven foundations, design of event bus and schema standards, vendor evaluation for core-system integration, phased roadmap with clear milestones, and a pilot of the first real-time use case in 6-9 months.

Related reading

• /en/architecture/telecom-around-core-architecture/ — layer around BSS/OSS
• /en/insights/telecom-subscriber-intelligence-operating-model/ — operating model
• /en/insights/telecom-sim-swap-banking-fraud/ — fraud in real time
• /en/insights/telecom-anti-scam-layer/ — anti-scam in real time

Sources

• Ministry of Digital Technologies — telecom infrastructure UZ
• Digital Government Portal — digital infrastructure UZ
• UzDaily — telecom market
• Central Bank of Uzbekistan — biometric verification for digital banking
• MNP.UZ — number portability