Коэффициенты в реальном времени без шторма запросов

Что требуется от потока данных

У live-коэффициента неприятная природа: он меняется часто, но пользователю важна не частота сама по себе, а согласованность цены и статуса рынка. Поэтому цель не «доставить каждое событие», а дать клиенту актуальный snapshot и затем дельты, которые можно безопасно применить в порядке версии.

• Первое открытие страницы не зависит от живого соединения: интерфейс получает snapshot обычным HTTP-запросом.
• Каждая дельта несёт market_id, version и состояние рынка; значение без версии не принимается.
• При разрыве последовательности клиент не пытается угадывать пропуск — запрашивает новый snapshot.

Где заканчивается приём данных и начинается выдача

Входной adapter превращает формат поставщика в нормализованное событие. Дальше поток расходится: одно направление обновляет snapshot, второе отправляет компактную дельту в stream gateway. Это важное разделение. HTTP-выдача не читает сырой фид, а stream gateway не является единственным источником истины.

Компромисс: не делать очередь из клиентского программный интерфейс

Если прокинуть каждую провайдерскую смену прямо до браузера, быстрый рынок легко создаст очередь у медленного клиента. На границе fan-out полезнее коалесцировать промежуточные версии: клиенту нужна последняя применимая цена, а не историческая лента микродвижений. Для действий, где нужна точная цена, всё равно работает серверная валидация.

Реализация контракта «снимок + изменение»

Snapshot содержит market_version для каждого рынка и generated_at. Stream сообщает только изменённые selection и новую версию. Клиент хранит версию рядом с локальным состоянием. Дельта с меньшей или равной версией игнорируется; скачок более чем на одну версию переводит компонент в короткое состояние resync.

• При resync кнопки цены визуально остаются на месте, но действие блокируется до нового snapshot.
• Событие suspend приоритетнее price update: состояние рынка нельзя «разбудить» запоздавшей ценой.
• Reconnect идёт с jitter, чтобы восстановление edge-узла не создавало синхронный шквал подключений.

Сценарии отказа, которые должны быть видны

Опасный отказ здесь тихий: соединение формально живо, но дельты перестали приходить. Поэтому heartbeat недостаточно. Нужен возраст последнего применённого market update и серверный признак lag. При превышении локального порога интерфейс лучше переводить рынок в suspended/refreshing, чем продолжать показывать цену как активную.

Практический бюджет свежести

Для live-потока полезно договориться о бюджете свежести на каждом участке: ingest, нормализация, snapshot, stream gateway и клиент. Один общий SLA скрывает место, где накапливается задержка. Если у каждой стадии есть timestamp и version, команда видит не только «данные старые», но и конкретный участок пути.

Бюджет не обязан быть одинаковым для всех рынков. Популярные live-события можно обслуживать с более строгими порогами, а менее критичные данные обновлять реже. Важнее, чтобы при выходе за допустимую свежесть продукт переходил в безопасное и понятное состояние вместо показа активной, но устаревшей цены.

• Считать age отдельно от транспортного heartbeat.
• На клиент отправлять версию и время генерации snapshot.
• При превышении порога сначала suspend/refresh, затем пытаться восстановить поток.

Одно обновление рынка не должно превращаться в сотню запросов

Типичная ошибка возникает, когда клиентский слой узнаёт об изменении и каждый виджет сам идёт в API за свежими данными. На популярном матче один provider tick запускает лавину одинаковых чтений. Гораздо устойчивее принять update один раз, применить его к нормализованному состоянию и раздать подписчикам версию изменившейся сущности.

При этом delta не заменяет snapshot. Новый клиент и клиент после reconnect должны получить полную точку отсчёта, а затем перейти к последовательным изменениям. LiveOddsTile не знает устройство provider feed: он получает продуктовый market state и его freshness. Это позволяет менять ingest без переписывания интерфейса.

Нагрузочный тест полезно строить по популярности событий, а не по среднему числу соединений. Пиковый матч показывает, выдерживает ли fan-out горячий ключ, granular subscriptions и backpressure, когда большинство пользователей смотрят одну и ту же сущность.

Что смотреть в эксплуатации

Для дежурного полезнее четыре сигнала: возраст snapshot по ключевым лигам, разница версий ingest→snapshot, число клиентов в resync и доля stream reconnect. Эти показатели объясняют путь данных. Средняя нагрузка на сервер сама по себе не ответит, почему конкретный рынок «застыл».