TRACK 05 / SPORTS APPS

Sports apps: state sync, latency и безопасное подтверждение

Опорный материал про клиентский слой: live center, betslip, мобильная задержка, смена состояния и recovery. UX обязан показывать изменение цены и доступности как факт системы, а не прятать его за универсальной ошибкой.

PRIMARY SIGNALstate sync / latency / confirmation
Технологическая инфраструктура и рабочие экраны
OPERATING QUESTION

Как интерфейс сообщает изменение цены, stale data и статус операции без ложного ощущения гарантии?

live center, betslip state, mobile latency, native/PWA/web, client recovery

Клиент — последняя граница распределённой системы

Sports app не просто визуализирует backend. Он кэширует, переподключается, повторяет запросы, переживает фон и слабую сеть. Поэтому состояние на экране может разойтись с сервером даже при исправном API. Архитектура клиента должна явно различать локальный snapshot и authoritative state.

Price changed, suspended и unavailable — не одна ошибка

У этих состояний разные причины и разные действия пользователя. Смена цены требует показать новое условие и запросить подтверждение; suspend означает временную недоступность; unavailable — окончательную невозможность продолжить выбранный сценарий. Универсальный красный toast скрывает важную часть state machine.

Reconnect должен приводить к свежему snapshot

После потери связи клиенту опасно бесконечно «доигрывать» локальную историю, если неизвестно, сколько updates пропущено. Надёжнее получить актуальный snapshot с version marker, сопоставить локальное состояние и только затем продолжить поток. Это особенно важно для live-center и betslip.

Latency раскладывается по границам

Пользователь чувствует end-to-end задержку: от нового feed state до рендера и реакции интерфейса. Server p95 не показывает queue wait, network variability и main-thread work на устройстве. Нужны timestamps по пути и возможность связать client event с backend trace.

Подтверждение — отдельная транзакционная операция

Повторный tap из-за слабой сети не должен создавать вторую операцию. Идемпотентность и явный operation state помогают безопасно переживать retry. Клиент не обязан знать внутреннюю реализацию, но должен честно показать pending, confirmed, rejected или changed state.

Выбор native/PWA/mobile web начинается с ограничений

Системные API, release cadence, offline/reconnect требования, distribution rules и стоимость поддержки важнее абстрактной моды на технологию. Решение полезно фиксировать как набор trade-offs, чтобы через год понимать, почему платформа выбрала именно этот клиентский контур.

Смежные досье: интеграционная архитектура, карта regulated infrastructure и reference card состояния.

МАТЕРИАЛЫ

Разборы client-state и delivery

Очередь построена от контракта и состояния к диагностике, восстановлению и проверке результата.

CONTROL MATRIX

Что проверить на клиентской границе

Authority

Где хранится authoritative state и как определяется версия?

Freshness

Как измеряется возраст состояния, а не только latency запроса?

Recovery

Что происходит после gap/reconnect/retry и как доказывается reconciliation?

Evidence

Какие trace/audit идентификаторы позволяют восстановить решение?

ПРАВИЛО ПРОВЕРКИ

Client latency измеряется end-to-end и по устройствам/сетевым условиям; server p95 не используется как замена пользовательскому времени.

СЛЕДУЮЩИЙ МАРШРУТ

Дальше: связать UI с live-data

Открыть индекс материалов