Реальное время: где задержка решает

Урок показывает на практике, почему «реальное время» — не модное слово, а измеримая бизнес-ценность.

Реальное время (real-time) в контексте данных — обработка события за миллисекунды-секунды после его появления, достаточно быстро, чтобы успеть повлиять на исход.

Зачем это нужно

Ценность данных часто убывает со временем. Знание «эта карта прямо сейчас расплачивается в трёх странах за минуту» стоит дорого, если успеть заблокировать операцию; через сутки это лишь строчка в отчёте о потерях. Реальное время — про то, чтобы действовать в окне, когда действие ещё имеет смысл.

Сценарии, где это критично

Сфера	Событие	Цена задержки
Антифрод	подозрительная транзакция	прямой денежный убыток
E-commerce	покупка последнего товара	овербукинг, отмена заказа
Рекомендации	клик по товару	устаревшая выдача, меньше конверсия
IoT / телеметрия	перегрев датчика	авария оборудования
Логистика	смена координат курьера	неточный ETA для клиента

Окно реакции

Полезно мыслить «окном реакции» — временем, в течение которого действие ещё что-то меняет. Для антифрода это доли секунды (до подтверждения платежа). Для пополнения склада — минуты. Для дашборда продаж — секунды-минуты. Архитектуру выбирают под самое узкое окно: если хоть одному потребителю нужны секунды, источник обязан публиковать события сразу, а не накапливать их к ночи.

{
  "event": "card_payment",
  "card_hash": "a91f...",
  "country": "BR",
  "amount": 250.00,
  "ts": "2026-06-24T12:03:41.880Z"
}

Антифрод-консьюмер читает такие события из Kafka и за миллисекунды сверяет с историей карты: три страны за минуту — стоп.

Как работает под капотом

Чтобы реальное время было настоящим, недостаточно «быстрого кода» — нужен транспорт с низкой и предсказуемой задержкой и без потерь под нагрузкой. Kafka даёт это за счёт того, что запись события — это просто добавление в конец лога (дешёвая последовательная операция), а доставка — чтение из этого лога потребителями почти сразу. Между «событие записано» и «потребитель его увидел» проходят единицы-десятки миллисекунд, и эта задержка стабильна даже при миллионах событий в секунду.

Частые ошибки

Гнаться за миллисекундами там, где хватает минут. Реальное время дороже в эксплуатации; применяйте его прицельно.
Забыть про конец конвейера. Если Kafka доставляет за 10 мс, но потребитель пишет в медленную БД, реального времени не будет — узкое место смещается.
Мерить среднюю задержку вместо хвостов. Для антифрода важен 99-й перцентиль (худшие случаи), а не среднее.

Итоги

Ценность данных часто убывает со временем; реальное время ловит окно, когда действие ещё работает.
Архитектуру выбирают под самое узкое «окно реакции» среди потребителей.
Kafka даёт низкую и предсказуемую задержку за счёт записи в конец лога и быстрого чтения.