Cloudflare перевела cdnjs, свой CDN для JavaScript и CSS библиотек, на Developer Platform. Для архитекторов здесь важен не сам факт миграции, а то, как была собрана новая схема доставки и публикации без изменения URL, содержимого пакетов и SRI-хэшей.
Проблема в cdnjs была не в трафике, а в раздвоении ответственности. Служба уже обслуживала около 9 млрд запросов в день, в среднем 108 000 запросов в секунду, при 98,6% cache hit rate. Но путь публикации оставался распределённым между Cloud Functions, Google Cloud Storage, Pub/Sub, виртуальной машиной с git-sync, GitHub и Workers KV. Такая схема работала, но усложняла сопровождение: один контур отвечал за выдачу файлов, другой — за их подготовку, и между ними постепенно накапливалась архитектурная инерция.
Cloudflare выбрала прагматичный путь консолидации. R2 стал source of truth для опубликованных файлов, KV — хранилищем метаданных, версий и SRI-хэшей, Workers — точкой входа для доставки, а Workflows — оркестратором публикации. Это не просто перенос компонентов в одну платформу. Это смена модели: от набора разрозненных интеграций к единому управляемому конвейеру, где можно отслеживать состояние и возобновлять обработку после сбоя. Компромисс тоже очевиден. Компания получила более цельную архитектуру, но сохранила fallback на DigitalOcean Spaces и внешний origin в предыдущей логике, потому что отказоустойчивость в таком сервисе нельзя строить на одном хранилище.
Реализация упёрлась в несколько технических ограничений. Пакеты теперь сначала проверяются по расписанию через workflow, который смотрит npm и GitHub на наличие релизов. Затем они загружаются в R2 и передаются в отдельные processing workflows для файлов. Эти workflow извлекают содержимое, минифицируют и сжимают ассеты, пишут результат обратно в R2, обновляют KV и синхронизируют Algolia search index. Такой пайплайн удобен для восстановления после ошибок, но он зависит от ограничений платформы. Для сжатия Cloudflare использует Containers, потому что текущие алгоритмы требуют буферизовать всю библиотеку в памяти. В Workers это пока не помещается в рамки удобной реализации, хотя компания и рассматривает streaming support как путь к переносу этой части обратно в Workers.
Особое внимание пришлось уделить неизменности байтов пакета. Для публичного CDN это не второстепенная деталь. Если меняется минификация или компрессия, меняются и SRI-хэши. А это уже ломает доверие к артефактам у потребителей. Поэтому миграция строилась так, чтобы сохранить существующие URL, содержимое пакетов и SRI hashes. В инженерных терминах это означает, что Cloudflare оптимизировала внутреннюю топологию, но не трогала внешний контракт сервиса.
Переход также вскрыл лимиты платформы. Cloudflare подняла лимит Worker subrequests с 1 000 до 10 миллионов, а лимит Workflow steps — с 1 024 до 10 000, с возможностью конфигурации до 25 000. Это важный сигнал: даже внутри собственной Developer Platform компании пришлось расширять границы, чтобы обслуживать производственный сценарий такого масштаба. В итоге cdnjs стал примером dogfooding не в маркетинговом смысле, а как проверка платформы на реальной нагрузке и на реальной сложности публикационного контура. Итоговая схема выглядит компактнее, но главное её достоинство в другом: она лучше объяснима, лучше наблюдаема и легче переносит сбои, чем прежняя связка из нескольких облачных систем.