Cloudflare Workers и R2 стали базой для cdnjs. Архитектура обслуживает 9 млрд запросов в день и меняет подход к CDN пайплайнам.
Система cdnjs упёрлась не в доставку, а в эволюцию. При 108 000 запросов в секунду и 98.6% cache hit rate слой выдачи работал стабильно. Деградация началась внутри пайплайна публикации. Новые версии библиотек было сложно обрабатывать, а изменения требовали координации между GCP Functions, VM и Cloudflare. Observability страдала: отладка превращалась в ручную сборку логов из разных систем. Это типичная точка роста highload-систем: не runtime, а developer velocity становится узким местом.
Решение — собрать всю систему на Cloudflare Developer Platform. В качестве источника истины выбрали R2, а KV оставили только для метаданных. Это прагматичный компромисс: KV оптимизирован под частые чтения и редкие записи, что идеально для SRI-хешей и версий. Workers Cache заменил отдельный слой кеширования, убрав лишнюю связность. Trade-off очевиден: сильная зависимость от одного вендора, но с выигрышем в управляемости и консистентности архитектуры.
Реализация показала, где платформа ещё “тонкая”. Пайплайн построен на Workflows: каждые 10 минут система проверяет npm и GitHub, скачивает пакеты в R2 и обрабатывает их. CPU-heavy операции, такие как сжатие, вынесли в Containers. Это важный паттерн: Workers остаются оркестратором, а тяжёлые задачи выполняются вне их ограничений. Связка Workflows + Queues + R2 events обеспечивает устойчивость: при сбое процесс продолжается с последнего шага. Для синхронизации тысяч файлов использовали Durable Objects как счётчик — простой, но надёжный механизм координации.
Критическая сложность возникла при миграции данных. Перегенерация файлов нарушала SRI-хеши из-за недетерминированности компрессии. Это ломает контракты с клиентами, где хеш зафиксирован. В итоге выбрали копирование “как есть” из KV в R2. Но здесь упёрлись в лимиты: 1 000 subrequests на Worker и 1 024 шага в Workflow. Решение — шардирование через Queues и параллельные инвокации. Показательно, что лимиты платформы были увеличены до 10 млн subrequests и до 25 000 шагов. Это редкий случай, когда нагрузка пользователя напрямую влияет на эволюцию платформы.
Результат — полностью унифицированная архитектура. cdnjs теперь работает на Workers, R2, KV, Queues и Containers без внешних зависимостей в пайплайне. Надёжность выросла за счёт цепочки cache → R2 → DigitalOcean как fallback. Observability улучшилась за счёт единой среды выполнения, хотя конкретные метрики не раскрываются. Система сохраняет ключевые свойства: отсутствие rate limiting, глобальная доступность и иммутабельные версии.
Интересный побочный эффект — влияние AI. LLM активно используют cdnjs из-за стабильных URL и накопленного корпуса данных. Это усиливает требования к неизменяемости и проверяемости (SRI). В этом контексте архитектура с R2 как source of truth и hash-верификацией выглядит не просто удобной, а необходимой.
В индустрии давно обсуждается перенос пайплайнов ближе к edge-инфраструктуре. cdnjs показывает, как это работает на практике: не через упрощение, а через разбиение задач и явную оркестрацию. Возможность в будущем трансформировать пакеты в ES modules прямо в пайплайне — логичное продолжение этой модели.