Опросы в прямом эфире при масштабе: приём «кэш и пурж»

Почему живой опрос ломает очевидное решение

Очевидная реализация — эндпоинт, который страница дёргает каждые несколько секунд. Он работает на тестах с пятью людьми и разваливается в проде, потому что живая аудитория синхронизирована так, как обычный веб-трафик не бывает никогда.

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

Привычный выход — WebSocket: держать соединение на каждого зрителя и пушить. Это работает, но вы взяли на себя состояние соединений, масштабирование сокетного слоя, штормы переподключений при сбоях мобильной сети и запасной путь для клиентов, которые не могут держать соединение.

Есть более простой вариант — и именно он у нас в проде.

Приём: один кэшируемый URL, пурж при изменении

Состояние опроса маленькое, одинаковое для всех и меняется редко — несколько раз за эфир. Это ровно та форма, ради которой и создан CDN.

Поэтому опубликуйте его как обычный кэшируемый JSON-URL. Зрители запрашивают этот URL, и отвечает ближайший edge. Ваш источник видит первый запрос в каждой локации и практически ничего после, сколько бы людей ни смотрело.

Когда ведущий открывает, закрывает или редактирует вопрос, бэкенд пуржит этот единственный URL. Следующий запрос промахивается мимо кэша, один раз забирает новое состояние, и все последующие зрители снова обслуживаются из кэша.

Интересное свойство — что происходит при росте аудитории: ничего. Десять тысяч зрителей или сто тысяч, источник всё равно видит один запрос на изменение на локацию. Затраты следуют за тем, как часто меняется опрос, а не за тем, сколько людей смотрит.

Как это выглядит в yayında.tv

yayında.tv — наша платформа прямых трансляций, и весь механизм именно такой.

На чтении — один эндпоинт, который отдаёт активный опрос с вопросами и вариантами в JSON и обслуживается через CDN. Он шлёт разрешающие CORS-заголовки, чтобы плеер мог забрать данные с любого домена, куда встроена трансляция. URL несёт хеш, выведенный из имени канала и серверного секрета: это мешает тривиальному перебору и при этом не ломает кэшируемость — URL стабилен для конкретного канала, то есть это настоящий ключ кэша, а не ключ на пользователя.

На записи — несколько строк в контроллере, который запускает или останавливает опрос: собрать тот же URL, вызвать API пуржа, готово. Ни очереди, ни рассылки, ни сокетного слоя — рассылку делает CDN.

// READ — what every viewer hits, cached at the edge
GET https://cdn.example.tv/{channel}/survey?s={hash}

{
  "status": "success",
  "survey": {
    "id": 42,
    "questions": [
      { "text": "Who takes the penalty?",
        "answers": [{"id": 1, "text": "..."}, {"id": 2, "text": "..."}] }
    ]
  }
}

// WRITE — the broadcaster opens the poll; the backend purges that one URL
cdnctl purge --account <account_uuid> \
             --path "/{channel}/survey?s={hash}" --type exact

// or straight from the app, on the same event that flips the poll live

И внутри плеера: Videoonly

Videoonly применяет ту же идею внутри видеоплеера. Взаимодействия в плеере — слой с вопросом, карточка спонсора, призыв к действию, привязанный к моменту эфира — это одна и та же по форме задача: небольшой кусок состояния, нужный всем зрителям и меняющийся тогда, когда оператор решил его поменять.

Поэтому плеер забирает конфигурацию слоёв с кэшируемого URL, а не опрашивает API по таймеру. Когда кто-то планирует или снимает слой, этот URL пуржится. Плеер подхватывает изменение при следующем запросе, а API вообще не находится на горячем пути.

Та же логика работает для всего с такими свойствами: табло счёта, строка «сейчас в эфире», фиче-флаги для живого события, обратный отсчёт, который можно прервать.

Как не испортить детали

Несколько вещей определяют, будет ли это гладко или мучительно на практике.

Держите URL стабильным. Всё, что уникально для пользователя, в пути или query — идентификатор сессии, антикэш-таймстамп — даёт каждому зрителю собственный ключ кэша, и вы снова бьёте по источнику за всех. Персонализации место во втором, отдельном запросе, а не в общем.

Ставьте TTL, с которым вы всё равно готовы жить. Быстрым изменение делает пурж, но конечный TTL — ваша страховка на день, когда вызов пуржа не сработает. Достаточно короткий, чтобы пропущенный пурж был заминкой, и достаточно длинный, чтобы источник оставался в покое.

Пуржите ровно тот URL, который отдаёте. Если кэшируемый объект — ?s=abc, а вы пуржите путь без query, ничего не инвалидируется и старый опрос остаётся на экране. Это самый частый способ, которым приём тихо ломается.

Разделяйте чтение и запись. Зрители читают кэшируемый URL; голоса идут на обычный, некэшируемый эндпоинт. Записи — малая доля от чтений: зритель голосует один раз и читает постоянно, так что путь записи может оставаться обычным.

Не кладите секреты в хеш URL. Это обфускация, а не авторизация: достаточно, чтобы отсечь случайный перебор, и это должно оставаться совместимым с кэшем. Всё, что действительно нуждается в защите, не место в общем кэшируемом объекте.

Когда всё-таки брать WebSocket

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

Он подходит, когда состояние общее для всех, маленькое и меняется в человеческом темпе: опросы, слои, табло, флаги. Он не подходит, когда каждому зрителю нужны свои данные, когда обновления непрерывны, а не эпизодичны, или когда нужна доставка быстрее секунды с гарантиями порядка. Живой чат — очевидный контрпример: индивидуальный, постоянный и чувствительный к задержкам. Там нужен сокетный слой.

Честная формулировка такова: большинство «реалтайм»-функций на странице трансляции вовсе не реалтайм. Это эпизодические изменения общего состояния, и кэшируемый URL плюс пурж решают их с долей от количества движущихся частей.