CDN - это не просто кеш ближе к пользователю, а архитектура про географию, иерархию кэшей, инвалидацию и защиту origin под мировым трафиком.
Кейс помогает увязать DNS или Anycast, edge POPs, TTL, purge, origin shielding и media delivery в одно решение, где freshness всегда спорит с cost и latency.
В интервью и design review он полезен тем, что быстро показывает, умеете ли вы думать о системе за пределами одного региона и видеть цену неверной cache policy.
Control Plane
Фокус на governance-политиках, лимитах, маршрутизации и стабильности edge-поведения.
Data Path
Нужно держать предсказуемую latency и throughput при росте трафика и burst-нагрузке.
Failure Modes
Покрывайте fail-open/fail-close, деградацию и безопасный fallback при частичных отказах.
Ops Ready
Показывайте мониторинг saturation, retry storm и operational guardrails.
Content Delivery Network (CDN) — это географически распределённая сеть серверов, которая кэширует и доставляет контент пользователям из ближайшей точки присутствия (PoP — Point of Presence). CDN критически важен для современных веб-приложений, снижая латентность и нагрузку на origin-серверы.
Источник
Acing the System Design Interview
Глава о CDN с детальным разбором архитектуры и trade-offs.
Зачем нужен CDN?
- Снижение латентности: контент доставляется с ближайшего edge-сервера
- Разгрузка origin: большинство запросов обрабатывается на edge
- Масштабируемость: горизонтальное масштабирование по географии
- Отказоустойчивость: если один PoP недоступен, трафик идёт на другой
- DDoS защита: распределённая инфраструктура поглощает атаки
Функциональные требования
Core функции
- Кэширование статического контента
- Географическая маршрутизация
- Cache invalidation
- Origin failover
Расширенные функции
- Dynamic content acceleration
- Edge computing
- SSL/TLS termination
- Request/response transformation
Нефункциональные требования
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Латентность | < 50ms (p99) | Пользователь не должен ждать загрузки |
| Cache Hit Ratio | > 95% | Минимизация нагрузки на origin |
| Availability | 99.99% | CDN — критическая инфраструктура |
| Throughput | Tbps+ | Обслуживание глобального трафика |
Архитектура CDN
Компоненты системы
1. DNS-based Routing
GeoDNS или Anycast DNS определяет ближайший PoP к пользователю. DNS-сервер возвращает IP-адрес edge-сервера с минимальной латентностью.
2. Edge Servers (PoP)
Кэширующие серверы в точках присутствия. Обрабатывают запросы пользователей, возвращают контент из кэша или проксируют на origin.
3. Origin Shield
Промежуточный кэширующий слой между edge и origin. Агрегирует cache misses от множества PoP, защищая origin от нагрузки.
4. Origin Server
Исходный сервер с контентом. CDN обращается к нему только при cache miss.
CDN Request Flow
Готово к запуску
Нажмите кнопку для демонстрации flow
Push vs Pull CDN
Push CDN
Контент загружается на edge-серверы заранее, до первого запроса пользователя.
Преимущества:
- Нет cold start — контент уже на edge
- Предсказуемая производительность
- Полный контроль над распространением
Недостатки:
- Требует ручного управления
- Избыточное хранение редкого контента
- Сложность синхронизации
Pull CDN
Контент кэшируется на edge при первом запросе пользователя (lazy caching).
Преимущества:
- Автоматическое кэширование
- Эффективное использование хранилища
- Простота настройки
Недостатки:
- Cold start для первого пользователя
- Нагрузка на origin при cache miss
- Менее предсказуемая латентность
Cache Invalidation
Одна из самых сложных проблем в CDN — инвалидация устаревшего контента. Существует несколько стратегий:
Cache Invalidation Strategies
TTL-based Expiration
Контент автоматически истекает после заданного времени жизни (Time-To-Live)
Преимущества
- •Простота настройки через HTTP заголовки
- •Не требует интеграции с CDN API
- •Предсказуемое поведение кэша
Недостатки
- •Задержка обновления до истечения TTL
- •Сложность выбора оптимального TTL
- •Нет мгновенной инвалидации
Caching Strategies
Что кэшировать?
| Тип контента | Кэшируемость | Рекомендуемый TTL |
|---|---|---|
| Статические файлы (JS, CSS) | Высокая | 1 год (с версионированием) |
| Изображения | Высокая | 1 месяц — 1 год |
| HTML страницы | Средняя | 5 мин — 1 час |
| API ответы (публичные) | Средняя | 1 мин — 1 час |
| Персонализированный контент | Низкая | Не кэшировать |
Cache Key Design
Cache key определяет уникальность записи в кэше. Неправильный дизайн приводит к cache pollution или низкому hit ratio.
# Простой ключ (только URL):
cache_key = hash(url)
# Расширенный ключ:
cache_key = hash(url + headers["Accept-Encoding"] +
headers["Accept-Language"] +
query_params["version"])
# Vary header указывает CDN, какие заголовки включать в ключ:
Vary: Accept-Encoding, Accept-LanguageSecurity Considerations
DDoS Protection
- Rate limiting на edge
- Anycast для распределения нагрузки
- Scrubbing centers
- Bot detection
SSL/TLS
- TLS termination на edge
- Shared vs Dedicated certificates
- Origin connection encryption
- HSTS, OCSP stapling
Access Control
- Signed URLs / Signed Cookies
- Token authentication
- IP whitelisting
- Geo-blocking
Origin Protection
- Origin Shield layer
- Request coalescing
- Secret origin hostname
- Firewall rules (CDN IP only)
Метрики и мониторинг
Процент запросов, обслуженных из кэша
Time to First Byte — латентность ответа
Объём переданных данных
Ключевые алерты:
- Cache Hit Ratio < 90% → проверить TTL и cache keys
- Origin 5xx > 1% → проблемы с origin сервером
- TTFB p99 > 100ms → проверить routing и origin latency
- Bandwidth spike → возможная атака или viral content
Вопросы на интервью
Как обеспечить консистентность при cache invalidation?
Использовать versioned URLs для immutable контента, purge API для срочных обновлений, и stale-while-revalidate для баланса между свежестью и производительностью.
Как защитить origin от thundering herd при cache miss?
Request coalescing (один запрос к origin, остальные ждут), Origin Shield, circuit breaker, и pre-warming кэша для популярного контента.
Push или Pull CDN — когда что использовать?
Push для небольшого объёма критического контента (software releases, main page assets). Pull для большого объёма user-generated контента с long-tail distribution.
Как кэшировать динамический контент?
Edge Side Includes (ESI), fragment caching, short TTL с stale-while-revalidate, или edge computing для генерации персонализированного контента на edge.
Ключевые выводы
- 1.CDN критически важен для глобального масштабирования — снижает латентность и нагрузку на origin
- 2.Cache invalidation — главная сложность; используйте комбинацию TTL, versioning и purge API
- 3.Origin Shield защищает origin от cache miss storms и снижает нагрузку
- 4.Push vs Pull — выбор зависит от характера контента и требований к свежести
- 5.Cache Hit Ratio > 95% — ключевая метрика эффективности CDN
Связанные главы
- Acing the System Design Interview (short summary) - даёт базовый interview-каркас для разбора CDN и помогает структурировать ответ по требованиям и trade-offs.
- Object Storage (S3) - раскрывает origin-слой CDN: хранение объектов, durability, lifecycle-политики и поведение при cache miss.
- Designing Data-Intensive Applications (short summary) - усиливает фундамент по репликации, консистентности и распределённым компромиссам в глобальной delivery-сети.
- Стратегии кэширования: Cache-Aside, Read-Through, Write-Through, Write-Back - дополняет практические решения по TTL, инвалидации и управлению cache hit ratio на edge-узлах.
- Лента видеохостинга - показывает high-bandwidth сценарий CDN для медиа-контента с геораспределённой доставкой.
- Domain Name System (DNS) - поясняет DNS-based routing и выбор ближайшего PoP через GeoDNS/Anycast-механики.
- Примеры задач по системному дизайну - ставит CDN-кейс в общий контекст interview-задач и облегчает сравнение с другими архитектурными паттернами.
- Uber/Lyft - даёт пример глобальной latency-sensitive системы, где edge-доставка и геораспределение критичны.
- URL Shortener (TinyURL) - показывает смежный кейс с глобальными редиректами, где CDN снижает задержки и разгружает origin.