СТРИМИНГ
Защищать origin через CDN, многоуровневую доставку и разумную политику старта потоков.
Спортивные продукты живут на синхронном спросе. Один важный момент может одновременно запустить видео, обновления счёта, push-уведомления и социальную активность.

Защищать origin через CDN, многоуровневую доставку и разумную политику старта потоков.
Раздавать счёт и статистику через событийные потоки, а не заставлять каждого клиента постоянно опрашивать backend.
Кэшировать read-heavy контент, оставляя идентификацию, покупки и персонализацию на контролируемых путях.
Связывать ошибки воспроизведения, API latency и региональный трафик, чтобы отличать локальную проблему от системной.

Предварительное масштабирование полезно для запланированных матчей, но одной мощности мало. CDN, объединение одинаковых запросов и fan-out через очереди не дают тысячам повторов добраться до origin.
Пользовательский опыт тоже должен деградировать осознанно. Если персональные рекомендации тормозят, live-счёт и видео должны продолжать работать, а не ждать вторичной функции.
Самый дешёвый запрос — тот, который ядро не обслуживает. Политика кэша и инвалидации часто даёт больше запаса, чем дополнительные экземпляры приложения.
Постоянные соединения требуют регионального распределения и back-pressure, особенно когда одно событие публикует обновления огромной аудитории.
On-demand контент кэшируется проще, поэтому разделение live и replay делает планирование ёмкости точнее.
Перед известным финалом или турниром команда может увеличить мощность, прогреть кэши, проверить синтетические сценарии и ограничить изменения критических систем. Такой режим снижает сюрпризы без постоянного избыточного резервирования.
Защищён ли origin, если cache hit rate резко упадёт?
Может ли live-лента масштабироваться без постоянного polling базы?
Какие вторичные функции отключаются первыми?
Видны ли отдельно региональные ошибки видео и API?
Отрепетирован ли failover во время живого события?