Сеть доставки контента решает не просто задачу кэша ближе к пользователю. Это система про географию трафика, иерархию кэшей, свежесть данных и защиту исходного слоя под глобальной нагрузкой.
Глава помогает связать маршрутизацию через систему доменных имен, точки присутствия, промежуточный защитный слой и время жизни объектов в одну архитектуру, где скорость ответа постоянно спорит со свежестью контента.
В интервью и инженерных обсуждениях этот кейс быстро показывает, умеете ли вы мыслить за пределами одного региона, считать цену промаха кэша и защищать origin при массовом трафике.
География трафика
Важно управлять тем, куда именно попадает пользовательский запрос: через маршрутизацию, ближайшую точку присутствия и резервные пути при сбое региона.
Иерархия кэшей
Пограничный кэш, промежуточный защитный слой и исходное хранилище должны работать как единая цепочка, а не как набор независимых узлов.
Свежесть контента
Нужно заранее определить, где хватает времени жизни, где нужен принудительный сброс, а где обязательны версионированные URL.
Защита origin
При промахах кэша и резких всплесках трафика важно ограничить число одновременных обращений к origin, объединять одинаковые запросы и иметь понятный режим деградации.
— это географически распределённая сеть серверов, которая кэширует и отдаёт контент пользователям из ближайшей . Для современных веб-приложений такая сеть уменьшает и снимает значительную часть нагрузки с исходных серверов.
Источник
Acing the System Design Interview
Подробный разбор архитектуры сети доставки контента, инвалидации кэша и ключевых компромиссов.
Зачем нужна сеть доставки контента?
- Снижение задержки: контент приходит с ближайшего пограничного узла
- Разгрузка исходного слоя: большая часть запросов завершается до обращения к исходному серверу
- Масштабируемость: трафик распределяется по регионам и точкам присутствия
- Отказоустойчивость: при сбое одной точки присутствия трафик можно увести на соседнюю
- Защита от массовых атак: распределённая инфраструктура лучше выдерживает всплески и злонамеренную нагрузку
Функциональные требования
Основные возможности
- Кэширование статического контента
- Географическая маршрутизация трафика
- Инвалидация и обновление кэша
- Переключение на резервный исходный сервер
Дополнительные возможности
- Ускорение динамического контента
- Выполнение простых вычислений на периферии
- Завершение защищённого соединения
- Преобразование запросов и ответов
Нефункциональные требования
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Задержка | < 50 мс (p99) | Пользователь не должен ждать начало загрузки |
| Доля попаданий в кэш | > 95% | Минимизировать нагрузку на исходный слой |
| Доступность | 99.99% | Это критическая часть внешнего контура сервиса |
| Пропускная способность | Tbps+ | Нужно выдерживать глобальный трафик и пиковые всплески |
Архитектура сети доставки контента
Компоненты системы
1. Маршрутизация через систему доменных имен
На входе работает . В глобальном контуре её часто дополняют GeoDNS и , чтобы направить пользователя в ближайшую точку присутствия с минимальной задержкой.
2. Пограничные узлы в точках присутствия
Эти узлы принимают пользовательские запросы, отдают данные из локального кэша и при необходимости проксируют запрос глубже по цепочке.
3. Промежуточный защитный слой
Промежуточный собирает промахи кэша от множества точек присутствия и не даёт исходному слою получить лавину одинаковых запросов.
4. Исходный сервер
Это сервер или объектное хранилище, к которому сеть обращается только тогда, когда контент не найден в промежуточных кэшах.
Путь запроса через сеть доставки контента
Готово к запуску
Нажмите кнопку, чтобы показать путь запроса.
Предварительная загрузка и кэширование по запросу
Если контент заранее известен и критичен для первой загрузки, его можно разложить по узлам заранее. Если библиотека постоянно меняется и состоит в основном из , чаще выбирают . У такого подхода есть цена: первый пользователь сталкивается с .
Предварительная загрузка
Контент раскладывается по узлам заранее, ещё до первого пользовательского запроса.
Преимущества:
- Нет задержки первого обращения
- Предсказуемая производительность
- Полный контроль над распространением
Ограничения:
- Нужно заранее управлять выкладкой
- Редкий контент занимает место зря
- Сложнее поддерживать синхронность между регионами
Кэширование по запросу
Контент попадает на пограничный узел только после первого запроса пользователя.
Преимущества:
- Автоматически подстраивается под реальный спрос
- Экономит место на редком контенте
- Проще в эксплуатации
Ограничения:
- Первый запрос платит за промах кэша
- Промахи увеличивают нагрузку на исходный слой
- Задержка менее предсказуема
Инвалидация кэша
Главный рычаг управления свежестью — правильно выбранное , понятный механизм принудительного сброса и правило, какие объекты можно обновлять в фоне, а какие нет.
Стратегии инвалидации кэша
Истечение по TTL
Контент автоматически перестаёт считаться свежим после заданного времени жизни.
Преимущества
- •Простая настройка через HTTP-заголовки
- •Не требует интеграции с API провайдера
- •Предсказуемое поведение кэша
Ограничения
- •Обновление ждёт истечения TTL
- •Сложно подобрать правильное значение
- •Нет мгновенной инвалидации
Стратегии кэширования
Что стоит кэшировать?
| Тип контента | Кэшируемость | Рекомендуемое время жизни |
|---|---|---|
| Статические файлы (JS, CSS) | Высокая | 1 год с версионированием |
| Изображения | Высокая | От 1 месяца до 1 года |
| HTML-страницы | Средняя | От 5 минут до 1 часа |
| Публичные API-ответы | Средняя | От 1 минуты до 1 часа |
| Персонализированный контент | Низкая | Обычно не кэшировать |
Проектирование ключа кэша
Ключ кэша определяет, какие версии контента считаются разными объектами. Ошибка на этом уровне приводит либо к загрязнению кэша, либо к низкой доле попаданий.
# Простой ключ (только URL):
cache_key = hash(url)
# Расширенный ключ:
cache_key = hash(url + headers["Accept-Encoding"] +
headers["Accept-Language"] +
query_params["version"])
# Заголовок Vary указывает, какие поля включать в ключ:
Vary: Accept-Encoding, Accept-LanguageБезопасность и защита исходного слоя
Внешний контур сети почти всегда принимает первую волну угроз и шифрования, поэтому здесь важны , корректное завершение , а также политики вроде и проверки сертификатов через .
Защита от массовых атак
- Ограничение частоты запросов на пограничном узле
- Эникаст для распределения всплесков трафика
- Центры очистки трафика
- Выявление ботов и аномалий
Шифрование соединений
- Завершение защищённого соединения на пограничном узле
- Общие и выделенные сертификаты
- Шифрование соединения с исходным сервером
- Строгая политика HTTPS и stapling статуса сертификатов
Контроль доступа
- Подписанные URL и cookies
- Токены доступа
- Белые списки IP-адресов
- Ограничения по географии
Защита исходного слоя
- Промежуточный защитный слой
- Объединение одинаковых запросов
- Скрытое имя исходного сервера
- Правила firewall только для IP-адресов сети доставки
Метрики и наблюдаемость
Для пользовательского пути особенно важно следить за , долей ответов из кэша и объёмом трафика, который доходит до исходного слоя.
Процент запросов, обслуженных без похода в исходный слой
Скорость, с которой пользователь получает первый байт ответа
Объём переданных данных и всплески по регионам
Ключевые алерты:
- Доля попаданий в кэш < 90% → проверить время жизни и структуру ключей
- Ошибки исходного слоя > 1% → проблема в origin или промежуточной защите
- Время до первого байта на p99 > 100 мс → проверить маршрутизацию и путь до исходного слоя
- Резкий всплеск трафика → возможна атака или внезапный рост популярности контента
Вопросы на интервью
Как обеспечить согласованность при инвалидации кэша?
Использовать версионированные URL для неизменяемого контента, API принудительного сброса для срочных обновлений и подходы вроде stale-while-revalidate там, где допустим короткий период устаревших данных.
Как защитить исходный слой от лавины одинаковых запросов при промахе кэша?
Использовать объединение одинаковых запросов, защитный слой origin, и предварительный прогрев кэша для популярных объектов.
Когда выбирать предварительную загрузку, а когда кэширование по запросу?
Предварительная загрузка подходит для ограниченного набора критичного контента. Кэширование по запросу лучше работает для больших библиотек и длинного хвоста редко востребованных объектов.
Как работать с динамическим контентом?
Использовать , кэширование фрагментов, короткое время жизни с stale-while-revalidate или для сборки персонализированного ответа ближе к пользователю.
Ключевые выводы
- 1.Сеть доставки контента критична для глобального масштаба: она уменьшает задержку и снимает нагрузку с исходного слоя.
- 2.Инвалидация кэша остаётся главным источником сложности, поэтому время жизни, версионирование и принудительный сброс нужно проектировать вместе.
- 3.Защитный слой origin снижает число одновременных обращений к исходному серверу и помогает переживать массовые промахи кэша.
- 4.Выбор между предварительной загрузкой и кэшированием по запросу зависит от характера контента, требований к свежести и цены промаха.
- 5.Доля попаданий в кэш и время до первого байта дают наиболее полезную картину того, как сеть доставки контента влияет на пользовательский путь.
Связанные главы
- Acing the System Design Interview (краткий обзор) - даёт базовую рамку для разбора кейса: требования, оценка масштаба, архитектура и ключевые компромиссы.
- Object Storage (S3) - раскрывает исходный слой: хранение объектов, долговечность, жизненный цикл данных и поведение при промахе кэша.
- Designing Data-Intensive Applications, 2nd Edition (short summary) - усиливает фундамент по репликации, консистентности и распределённым компромиссам в глобальной сети доставки.
- Стратегии кэширования: Cache-Aside, Read-Through, Write-Through, Write-Back - дополняет практику выбора времени жизни, инвалидации и управления долей попаданий в кэш на пограничных узлах.
- Лента видеохостинга - показывает тяжёлый медиасценарий, где геораспределённая доставка и защита исходного слоя становятся критичными.
- Система доменных имен (DNS) - поясняет маршрутизацию через систему доменных имен и выбор ближайшей точки присутствия с помощью GeoDNS и эникаста.
- Примеры задач по системному дизайну - ставит задачу про сеть доставки контента в общий контекст интервью и облегчает сравнение с другими архитектурными кейсами.
- Uber/Lyft - даёт пример глобальной системы с жёсткими требованиями по задержке, где распределение трафика между регионами критично.
- URL Shortener (TinyURL) - показывает смежный сценарий с глобальными редиректами, где ответ ближе к пользователю разгружает исходный слой.