Real-time decisioning: what should resolve in milliseconds and what should not

Polarisation in the discussion

In modern telecom architecture discussions polar positions are common. One side: “everything has to be real-time, batch is the old model”. The other: “real-time is hype, daily updates are enough for most tasks”.

Neither is accurate. The reality is that different decision classes have different timing requirements, and the architecture has to reflect that. Doing everything real-time is overengineering and cost. Doing everything batch misses critical capabilities.

Four categories by timing

Decisions in telecom split into four classes by timing requirements.

Class 1 — milliseconds. Transactional decisions that block a user-facing flow. Authorise the transaction. Allow the call. Block the SMS. These have to complete in milliseconds because the user or the system is waiting.

Class 2 — seconds. Decisions that affect the current user session. Which NBA to show in the app. Which fraud signal to send the bank partner. Which compensation to offer at the moment of complaint. The user or system waits seconds — not milliseconds, but not hours.

Class 3 — minutes. Decisions that act in the short term but do not block. When to send the retention call. Which campaign triggers on an event. Which signal to escalate to network ops. The user is not waiting, but the commercial window is open for a limited time.

Class 4 — hours or days. Strategic, planning, reporting decisions. Which segment to include in the weekly campaign. Which network capacity plan for next quarter. Which margin trends across the month. Real-time delivers no value — overhead exceeds benefit.

Each class needs its own architecture, tools, operations.

Where mistakes are usually made

Several typical errors in choosing timing for a decision.

Class 4 in real-time. Building a dashboard that refreshes every 5 seconds for a metric that changes monthly. Infrastructure cost high, value minimal.

Class 1 in batch. Authorising transactions through a batch process. Unacceptable — the customer is waiting.

Class 2 in hours. Triggering NBA via a nightly batch. By the time of delivery the context is no longer relevant.

Class 3 in microseconds. Building infrastructure for retention notifications as if it were real-time. Overinvested.

The mismatch is often created because the architecture team wants a “modern stack” (everything in kafka, real-time, streaming), not driven by clearly articulated business requirements. Or because legacy systems forced the batch model and the architecture was not updated even where modern requirements appeared.

What the right architecture looks like for each class

Class 1 (milliseconds). Synchronous APIs with tight SLA. In-memory caching of data needed for the decision. Pre-computed decision rules where possible. Fast failover paths. Examples — fraud blocking on transactions, anti-scam blocking on calls, SIM authentication.

Class 2 (seconds). Stream processing with low latency. Real-time but not synchronous — can work with a small queue. State in fast storage. Examples — NBA in the app, real-time signals to partners, in-session offers.

Class 3 (minutes). Event-driven with slower processing. Can go through cross-system integrations. Examples — campaign triggers, retention notifications, complaint escalations.

Class 4 (hours or days). Batch processing. DWH-based analytics. Reports on a fixed schedule. Examples — weekly campaign planning, monthly margin reports, quarterly capacity planning.

If the architecture is built correctly to class — the overall system is efficient. Cross-class — either underperforms or overcosts.

What often becomes a barrier

Architecture decisions without business clarity. Architecture team makes timing decisions on technical preference, not on clearly articulated business requirements.

Vendor capabilities. Some vendor systems force timing on their native model — batch-only billing, daily-only marketing automation. Architecture choices are constrained.

Skill mismatch. Real-time engineering needs different skills from batch. If the team is strong in only one, architecture is biased.

Cost overengineering. Modern “enterprise grade” streaming platforms are expensive. Spending on real-time infrastructure where the business does not need it is wasted resource.

Politics. Different teams want their decisions to be “real-time” as status. CMO wants “real-time marketing”, CRO “real-time risk”, CTO “real-time operations”. Without strict business case prioritisation, everyone claims real-time.

Discussion points for the committee

Which 5-10 key business decisions today are taken slowly and where would faster create value?

What is the current architecture per decision? Does it match the right class?

Who has the authority to decide architecture timing — the architecture team or business?

What incremental investment in real-time capability is justified by a clear business case? Not generic “modernisation”.

Which vendor constraints on timing cannot be changed and which can?

How SamaraliSoft can help

Decisioning Architecture Review — classification of key business decisions by timing requirements, gap analysis against current architecture, prioritisation of investment in real-time capabilities where the business case is clear, vendor evaluation for capability upgrade, and a phased rollout with a pilot on 1-2 high-priority decisions over 90-120 days.

Related reading

• /en/insights/telecom-event-driven/ — event-driven foundation
• /en/insights/telecom-data-contracts/ — data contracts
• /en/architecture/telecom-around-core-architecture/ — layer around the core
• /en/insights/telecom-nba/ — NBA as context

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