Vercel, sharded route metadata ile CDN metadata lookup P99 gecikmesini %91 azalttı

Vercel, CDN metadata lookup'ları için P99 gecikmesini %91 azalttığını, routing metadata'sının saklanma ve getirilme şeklini değiştirerek — path başına tek bir cache girdisi yerine shard adı verilen sınırlı path gruplarına geçerek — başardığını bildiriyor. CDN ortalama olarak saniyede 80 milyondan fazla routing işlemi yürütüyor ve Vercel blog'unda yayımlanan bir yazıya göre bu değişiklik deployment'ları da hızlandırdı.

Path başına fetch'ten shard'lara

Vercel'in CDN'ine gelen her isteğin, hangi hedef path'lerin mevcut olduğunu ve bunların nasıl sunulacağını çözmesi gerekiyor. URL'deki path çoğu zaman temeldeki kaynakla eşleşmez: /blog/hello-world gibi bir istek /blog/[slug] gibi dinamik bir route'a çözümlenebilir ve CDN, doğru yanıtı bulmadan önce birkaç aday path'i kontrol etmesi gerekebilir. Bloom filter'lar kesinlikle var olmayan path'leri zaten eler; geriye kalan her şey için kesin bir metadata lookup gerekir.

Vercel daha önce bu metadata'yı her hedef path için ayrı bir nesne olarak saklıyor, her birini bağımsız şekilde fetch'leyip önbelleğe alıyordu. Bu, nadiren deploy olan küçük projeler için işe yarasa da, büyük deployment'lar yüz binlerce path içerebiliyor ve her deployment yeni bir cache key seti oluşturuyor. Bu yüzden cache miss'ler sık yayın yapan büyük siteler için tekrarlayan bir maliyet haline gelmişti; ayrıca eski akış path başına bağımlı bir HEAD ve GET gerektiriyordu.

Çözüm, birçok path'in metadata'sını shard'lar halinde gruplandırmak ve her shard'ı boyut açısından sınırlı tutmaktı; böylece tek bir lookup sınırlı miktarda veri fetch'liyor. Bir shard'ı fetch'lemek, içindeki tüm path'ler için cache'i ısıtıyor ve bu path'lere yapılan sonraki lookup'lar yerel olarak karşılanıyor.

Her şeyi parse etmeden hızlı fetch'ler

Bir shard'ı getirmek sadece CDN'in tamamını decode etmek zorunda olmadığı durumlarda işe yarar. Her shard, her girdinin nerede başladığını işaretleyen sabit genişlikli pointer'lardan oluşan bir index içerir; pointer'lar altı bitlik Base64 karakterlerinin tam sayıları olarak boyutlandırılır, böylece herhangi biri index satırını önce JSON olarak parse etmeden yerinde decode edilebilir. Routing süreci, build zamanındaki byte offset'lerini kullanarak encode edilmiş path'ler üzerinde binary search yapar; O(log n) pointer okuması ve string karşılaştırması gerçekleştirir, ardından yalnızca bir sonraki satırdaki eşleşen metadata değerini parse eder. Shard'ın geri kalanı hiçbir zaman parse edilmez.

Bu düzen Vercel'in diğer sistemlerinden teknikleri yeniden kullanıyor: Bulk Redirects veri setinden alınan sıralı, dönüşümlü anahtar-değer JSONL kayıtları ve aslen Bloom filter'lar için geliştirilmiş doğrudan adreslenebilir Base64 yapıları. Bir deployment için ilk metadata fetch'i zaten hangi shard'ın verilen bir path'i içerdiğini belirliyor, dolayısıyla shard seçimi ek bir round trip eklemiyor.

Doğru shard boyutunu bulmak

Vercel başlangıçta çok megabaytlık shard'lar denedi; bölge başına paylaşılan daha büyük bir cache'in önündeki küçük bir in-process LRU cache'in bunları sıcak tutacağına bahse girdi. Pratikte bölgesel cache hit oranı yüksekti ama LRU hit oranı düşüktü; çünkü istekler her bölgede birçok sürece yayılıyordu ve çok megabaytlık shard'ların aktarımı beklenenden daha pahalıya geliyordu. Çok küçük shard'larda ise tersi problem vardı: bölgesel miss'ler fazla sıklaşıyordu. Production testleri yaklaşık 200 KB'lık shard'larda karar kıldı; Vercel'e göre bu boyut bölgesel hit oranlarını yüksek tutarken LRU miss'lerinin doldurulmasını ucuzlatıyor. Bildirilen gecikme rakamları 5–12 Ağustos 2026 tarihleri arasında production trafiğinde ölçüldü.

Ekip shard'ları daha da küçültmeyi de değerlendirdi: sıralı path'lerde front-coding, JSONL dokümanları arası metadata deduplication'u ve daha kompakt özel bir serialization formatı. Offline simülasyonlar çok daha küçük shard'lar üretti ama yalnızca mütevazı gecikme kazançları öngördü; bu yüzden eklenen encoding, uyumluluk ve rollout yükünün bu migration'a değmeyeceği düşünüldü.

Güvenli rollout

Bu lookup her deployment'a gelen isteklerde çalıştığı için, eski ve yeni formatlar arasındaki bir uyuşmazlık bayat bir route, yanlış bir status code ya da var olan bir path için 404 döndürebilirdi. Vercel önce offline doğrulama yaptı: bir harness, test deployment'larındaki her path'i her iki yöntemle lookup etti ve yanıtları karşılaştırdı. Ardından production'da "shadow mode" adını verdiği yöntemi yürüttü: bir feature flag arkasında, rastgele örneklenmiş istekler her iki lookup'ı da yaptı, eski sonucu servis etti ve yanıtları istekleri yavaşlatmadan birkaç hafta boyunca arka planda karşılaştırdı.

Farklılıklar son derece nadirdi. Bunlardan biri eski encoding'deki bir bug olduğu ortaya çıktı; bu encoding path'leri RFC 2047 encoded word'lerine paketliyordu ve bir emoji iki word'e bölündüğünde ortaya çıkıyordu. Yeni format path'leri düz UTF-8 olarak saklıyor, dolayısıyla bu sınıf bir bug tekrarlayamaz.

Neden önemli

Bu, temel edge-performance ödünleşimine dair net bir vaka çalışması: round trip'leri azaltmak için veriyi toplu hale getirmek ile bir isteğin ihtiyacından fazlasını fetch'lemek arasındaki denge. Vercel'in rakamları, daha ağır compression yöntemlerine başvurmadan önce yalnızca veri düzeninde ne kadar alan bulunabileceğini gösteriyor — şirket bunun karmaşıklığına değmeyeceğini kendisi de tespit etti. Sınırlı shard'lar, yerinde decode edilebilir pointer'lı inline index'ler ve bir routing değişikliğinden önce shadow-mode doğrulaması gibi teknikler, routing tablolarını veya konfigürasyonu büyük ölçekte edge altyapısına dağıtan herkes için yeniden kullanılabilir desenlerdir.