cdn-design.js·5 scenarios
CDN system design case: client → DNS (anycast) → edge PoP (cache + WAF + Worker) → tiered cache (regional + origin shield) → customer origin, with global control plane (config, purge, logs). 5 scenarios: edge cache hit, tiered miss fetch, global purge fan-out, DDoS absorption, video chunked streaming. 2 ADRs: anycast vs GeoDNS, push vs pull CDN. Capacity hints on every node.
CDN является одним из самых практичных кейсов системного дизайна: почти каждый современный продукт отдает через edge изображения, JavaScript, CSS, видео, downloads, API-cache или protected media. Пользователь ожидает низкую latency из любой точки мира, а origin не должен падать из-за всплеска трафика, DDoS или viral asset. Хороший CDN уменьшает RTT, снижает egress с origin, терминирует TLS ближе к клиенту и дает control plane для purge, configuration, certificates и analytics.
Кейс полезен потому, что в нем сочетаются networking, caching, storage hierarchy, consistency, observability and operations. Нужно объяснить, как пользователь попадает в ближайший PoP, что происходит при cache hit, как обрабатывается miss, зачем нужны regional cache и origin shield, почему purge не мгновенный, как защищаться от stampede и DDoS, и почему edge functions не должны превращать CDN в полноценный backend.
Этот дизайн связан с ::concept{slug="cdn-edge-network"}, ::concept{slug="caching-strategies"}, ::concept{slug="dns"}, ::concept{slug="multi-region"}, ::concept{slug="http-protocol"}, ::concept{slug="rate-limiting"} и ::concept{slug="observability"}. Он также помогает лучше понимать Pastebin, Instagram, video streaming and software distribution systems.
Мысленная модель CDN: это распределенный cache hierarchy перед customer origin. Пользователь делает HTTPS-запрос к домену, DNS или Anycast направляет его в близкий edge PoP, L4/L7 балансировщик выбирает cache node, WAF проверяет request, cache node строит cache key из host, path, query, selected headers and Vary. При hit edge сразу возвращает response. При miss edge идет в regional cache, затем в origin shield, затем в customer origin. Ответ постепенно заполняет shield, regional and edge layers.
Control plane живет отдельно от data plane. Data plane обслуживает миллионы RPS и должен продолжать работать даже при деградации control plane. Control plane хранит customer config, routing rules, certificates, cache policies, purge requests, worker code and rollout state. Он распространяет конфигурацию на PoPs асинхронно, с versioning and rollback.
Anycast и GeoDNS решают похожую задачу, но с разными trade-offs. GeoDNS проще и часто достаточно хорош, но resolver может быть далеко от пользователя, а DNS TTL замедляет failover. Anycast сложнее в эксплуатации, требует BGP announcements и network expertise, зато сеть сама направляет flow к ближайшему доступному PoP и быстрее реагирует на withdraw.
Диаграмма показывает user, DNS/Anycast, Edge PoP с L4 LB, WAF, cache nodes и Worker, затем tiered cache: regional cache и origin shield, дальше customer origin. Отдельно показан global control plane с Config Service, Purge Service and Logs/ClickHouse.
Edge PoP на диаграмме является местом, где происходит самая большая экономия latency. TLS termination, WAF checks, cache lookup и simple worker logic выполняются рядом с пользователем. Regional cache уменьшает количество обращений к origin shield от множества edge nodes одного региона. Origin shield защищает customer origin от fan-in: вместо сотен PoPs к origin ходит ограниченное число shield nodes.
Logs/analytics вынесены отдельно, потому что access logs могут иметь огромный объем. Их нельзя синхронно писать в transactional DB на каждый request. Обычно edge буферизует logs, сжимает и отправляет batch в streaming/columnar pipeline.
Edge cache hit показывает лучший путь: browser идет через Anycast в ближайший PoP, request проходит TLS and WAF, cache node находит object и возвращает response за единицы миллисекунд. Origin вообще не участвует. Это главный value proposition CDN.
Tiered miss учит cold path. Edge не нашел объект, regional тоже miss, shield тоже miss, только после этого request идет к customer origin. Ответ возвращается обратно и заполняет все уровни. Первый пользователь платит 80-200 ms, следующие получают edge hit.
Global purge fan-out показывает consistency trade-off. Customer деплоит новый CSS или отзывает asset и вызывает purge API. Purge service распространяет invalidation на edge, regional and shield. Реальный SLA часто измеряется секундами, а не миллисекундами, поэтому для критичных объектов лучше использовать versioned URLs вроде /app.abcd1234.css.
DDoS absorption показывает network-side защиту. Anycast распределяет трафик по PoPs, L4 layer отбрасывает spoofed SYN, WAF применяет rate limits and challenges, origin остается защищенным. Это работает только если origin не раскрыт напрямую и принимает traffic только от CDN.
Video chunked streaming показывает, почему CDN особенно важен для media. HLS/DASH manifest и segments кэшируются отдельно, range requests и single-flight защищают origin при первом запросе popular chunk, а последующие viewers получают segment из edge cache.
Pull CDN проще для customer: достаточно поставить CNAME и Cache-Control на origin. Цена: cold misses и непредсказуемая cache warmth по PoPs. Push CDN дает предсказуемое pre-warming для больших релизов, но требует upload workflow и хранит много холодных объектов. На практике pull является default, а pre-warm используется для известных hot launches.
Anycast дает быстрый failover и хорошую latency, но требует BGP operations and monitoring. GeoDNS проще, но страдает от resolver inaccuracy и TTL. Многие сети комбинируют оба подхода: DNS выбирает регион или provider, Anycast работает внутри edge network.
Long TTL повышает hit ratio и защищает origin, но усложняет обновление и revoke. Short TTL дает свежесть, но увеличивает origin load. Versioned assets снимают конфликт: immutable files получают долгий TTL, HTML and API responses получают короткий TTL или revalidation.
Edge Workers дают гибкость: auth check, header rewrite, A/B routing, image resize, lightweight personalization. Но worker runtime должен иметь CPU/time limits. Если на edge перенести тяжелую бизнес-логику, операционная модель CDN превратится в распределенный application platform со сложным state management.
Origin shield снижает stampede, но добавляет hop для cold requests. Для static assets это приемлемо, для latency-sensitive dynamic API нужно осторожно выбирать правила кэширования и shield region.
Cloudflare, Fastly, Akamai, Amazon CloudFront, Google Cloud CDN и Azure Front Door реализуют разные варианты этой архитектуры. Cloudflare активно использует Anycast and Workers, Fastly известен Varnish-подходом и быстрым purge, Akamai исторически силен в крупной глобальной edge-сети, CloudFront тесно связан с AWS origins and Lambda@Edge.
Для video streaming CDN обслуживает manifests and chunks, для ecommerce защищает product images and static JS, для SaaS разгружает downloads and API cache, для gaming распространяет patches. Внутри больших компаний может существовать internal CDN для артефактов сборки, container layers and machine learning datasets.
В observability часто используются sampled logs, real-user monitoring, per-PoP hit ratio, origin error rate, TLS handshake metrics, cache status headers and purge propagation metrics. Без этих сигналов CDN превращается в черный ящик.
Кэшировать personalized HTML без правильного cache key. Если забыть Vary: Cookie или authorization handling, один пользователь может получить страницу другого.
Полагаться на purge вместо versioned assets для каждого deploy. Purge нужен, но immutable asset filenames дают гораздо более надежную модель.
Открывать origin напрямую в интернет без allowlist CDN ranges or signed origin requests. Тогда attacker может обойти WAF and rate limits.
Не защищаться от cache stampede. Если популярный объект истек, тысячи edge requests могут одновременно пойти к shield или origin. Нужны request coalescing, stale-while-revalidate, soft TTL and origin shielding.
Считать hit ratio единственной метрикой. Важны byte hit ratio, p95/p99 latency, origin offload, error rate, purge SLA, regional imbalance and cache eviction reasons.
Использовать query string хаотично. Если cache key включает весь query, случайные tracking parameters могут уничтожить hit ratio. Если query игнорируется полностью, можно склеить разные responses.
CDN не решает проблему strongly consistent dynamic reads. Если каждый response уникален, зависит от private state и не может быть safely cached, edge даст только TLS termination and WAF, но не уменьшит origin compute.
Он не заменяет multi-region backend. CDN может пережить origin outage для cached static assets, но не выполнит write transaction, не обновит ledger и не восстановит database consistency.
CDN также не должен быть единственным security layer. WAF полезен, но application authorization, input validation, secrets management and audit остаются обязанностью origin services.
Для маленького internal tool в одной локации CDN может быть лишним. Достаточно регионального load balancer and simple cache. Но как только появляются global users, large media or public downloads, CDN почти всегда окупается.
Начните с ::concept{slug="http-protocol"} и ::concept{slug="dns"}, чтобы понимать headers, caching directives and routing. Затем изучите ::concept{slug="cdn-edge-network"} и ::concept{slug="caching-strategies"}: они объясняют PoP, TTL, revalidation, stale-while-revalidate and cache keys. Для глобального failover полезен ::concept{slug="multi-region"}. После этого сравните CDN case с Pastebin raw view and Instagram media delivery: оба используют edge cache, но разные constraints по privacy, invalidation and object size.