Real-time decisioning: что должно решаться в миллисекунды, а что нет

Поляризация в обсуждении

В обсуждении современной telecom-архитектуры часто звучат полярные позиции. Одни — «нужно всё в реальном времени, batch — старая модель». Другие — «real-time — это hype, для большинства задач достаточно ежедневных обновлений».

Ни одна позиция не точна. Реальность — у разных классов решений разные требования к timing, и архитектура должна это отражать. Делать всё в реальном времени — overengineering и cost. Делать всё batch — упускать критические возможности.

Четыре категории по timing

Решения в телекоме можно разделить на четыре класса по требованиям к timing.

Класс 1 — миллисекунды. Транзакционные решения, которые блокируют user-facing flow. Авторизовать ли транзакцию. Разрешить ли звонок. Заблокировать ли SMS. Эти решения должны завершаться в миллисекундах, потому что пользователь или система ждут.

Класс 2 — секунды. Решения, которые влияют на текущую сессию пользователя. Какое NBA показать в приложении. Какой fraud-сигнал послать банковскому партнёру. Какую компенсацию предложить клиенту в момент жалобы. Пользователь или система ждут несколько секунд — может, не миллисекунды, но не часы.

Класс 3 — минуты. Решения, которые срабатывают в краткосроке, но не блокируют. Когда отправить retention-звонок. Какая кампания триггерится по событию. Какой сигнал эскалировать в network ops. Пользователь не ждёт, но коммерческое окно открыто ограниченно.

Класс 4 — часы или дни. Стратегические, плановые, отчётные решения. Какой сегмент включить в недельную кампанию. Какой network capacity plan на следующий квартал. Какие тренды маржи за месяц. Real-time не даёт ценности — overhead превышает benefit.

Каждый класс требует свою архитектуру, свои инструменты, свои операции.

Где обычно ошибаются

Несколько типичных ошибок в выборе timing для решения.

Класс 4 в real-time. Сборка дашборда, который обновляется каждые 5 секунд для метрики, меняющейся ежемесячно. Стоимость инфраструктуры высокая, ценность минимальная.

Класс 1 в batch. Авторизация транзакций через batch-процесс. Это неприемлемо — клиент ждёт.

Класс 2 в часах. Триггер NBA через nightly batch. К моменту доставки контекст уже не релевантен.

Класс 3 в микросекундах. Сборка инфраструктуры для retention-уведомления как если бы это был real-time. Overinvested.

Несоответствие создаётся часто потому, что architecture team хочет «modern stack» (всё в kafka, real-time, streaming), не основываясь на бизнес-требованиях. Или наоборот — потому что legacy-системы forced на batch-модель, и архитектура не обновлена даже там, где появились современные требования.

Что значит правильная архитектура для каждого класса

Класс 1 (миллисекунды). Synchronous API с tight SLA. In-memory caching данных, нужных для решения. Decision rules pre-computed где возможно. Быстрые failover paths. Примеры — fraud blocking на транзакциях, anti-scam blocking на звонках, аутентификация SIM.

Класс 2 (секунды). Stream processing с low latency. Real-time, но не synchronous — может работать с небольшой очередью. State в fast storage. Примеры — NBA в приложении, real-time-сигналы партнёрам, in-session offers.

Класс 3 (минуты). Event-driven с медленной обработкой. Может ходить через cross-system integrations. Примеры — триггеры кампаний, retention-уведомления, эскалации жалоб.

Класс 4 (часы или дни). Batch processing. DWH-based analytics. Отчёты по fixed schedule. Примеры — недельное планирование кампаний, ежемесячные отчёты по марже, квартальное планирование capacity.

Если архитектура построена корректно по классам — система в целом эффективна. Если cross-class — либо underperforms, либо overcosts.

Что часто становится барьером

Architecture-решения без бизнес-ясности. Architecture team принимает решения о timing на основе технических предпочтений, не на основе явно артикулированных бизнес-требований.

Vendor capabilities. Некоторые vendor-системы forceят timing на свою native-модель — batch-only billing, daily-only marketing automation. Architecture choices ограничены.

Skill mismatch. Real-time engineering требует других навыков, чем batch. Если команда сильна только в одном, архитектура смещена.

Cost overengineer. Современные «enterprise grade» streaming-платформы дороги. Затраты на инфраструктуру для real-time, когда бизнесу не нужно, — wasted resource.

Политика. Разные команды хотят, чтобы их решения были «real-time» как статус. CMO хочет «real-time marketing», CRO — «real-time risk», CTO — «real-time operations». Без строгой приоритезации по business case все claim real-time.

Что обсудить на committee

Какие 5-10 ключевых бизнес-решений сегодня принимаются медленно и где быстрее даст ценность?

Какова текущая архитектура для каждого решения? Соответствует ли правильному классу?

Кто authority решать timing архитектуры — architecture team или бизнес?

Какая incremental-инвестиция в real-time-возможности оправдана явным business case? Не общая «modernisation».

Какие vendor-ограничения на timing нельзя изменить и какие можно?

Что может сделать SamaraliSoft

Decisioning Architecture Review — классификация ключевых бизнес-решений по требованиям к timing, gap-анализ с текущей архитектурой, приоритезация инвестиций в real-time-возможности там, где бизнес-кейс ясен, оценка вендоров для апгрейда возможностей, и поэтапный rollout с пилотом на 1-2 высокоприоритетных решениях в течение 90-120 дней.

Внутренние ссылки

• /insights/telecom-event-driven/ — событийный фундамент
• /insights/telecom-data-contracts/ — data contracts
• /architecture/telecom-around-core-architecture/ — слой вокруг core
• /insights/telecom-nba/ — NBA как контекст

Источники

• Министерство цифровых технологий — телеком инфраструктура УЗ
• Digital Government Portal — digital infrastructure UZ
• UzDaily — рынок телекома
• ЦБ РУ — биометрическая верификация digital banking
• MNP.UZ — портабельность