2 Kasım 2026, Pazartesi

Cloudflare’in DNS propagation pipeline’ındaki Zone Builder, 2022’de saniyede yaklaşık 250 DNS kayıt değişikliği alıyordu; bugün yaklaşık 700 (ayrıca yaklaşık 100 zone ayarı gibi başka olay). Yazının tespiti: sorun olay sayısı değil, bazı olayların gerektirdiği işin türü ve bu işin zone büyüklüğüyle büyümesi. Bazı zone’lar artık 20 milyondan fazla kayıt tutuyor ve yüzlerce milyona doğru büyümesi bekleniyor. Her olay bir saat başlatıyor: değişikliğin authoritative DNS sunucularının kullanabileceği veriye dönüşme süresi. Bu işe build deniyor: build, veritabanındaki mevcut durumu okuyor, edge’de kullanılan biçime çeviriyor ve değişenleri Quicksilver’a (dağıtık key-value store) yazıyor.

Pipeline. Müşteri bir kaydı API ya da dashboard ile değiştirir ya da başka bir Cloudflare servisi bir zone ayarını değiştirir; değişiklik veritabanına yazılır; bir Kafka olayı üretilir; DNS Kafka Aggregator birkaç topic’ten gelen olayları birleştirip Zone Builder’a verir; Zone Builder gerekli zone verisini okuyup DNS sunucularının anladığı key’lere çevirir, bu key’leri Quicksilver’la karşılaştırır ve yalnızca değişeni yazar.

Full build neden ölçeklenmedi? Orijinal Zone Builder’ın tek bir faydalı özelliği vardı: zone’un neden değiştiğini bilmesi gerekmiyordu, mevcut veritabanı durumundan istenen durumu baştan kuruyordu. Yani zone’u ve ayarlarını oku, her DNS kaydını oku, hepsini Quicksilver key’lerine çevir, eskilerle karşılaştır, eskiyi sil ve değişeni yaz. Son yazma yalnızca değişeni içerse de full build her kaydı yine okuyor, encode ediyor ve karşılaştırıyor ve bunu yaparken tüm zone’u bellekte tutuyor. Küçük zone’da ucuz; onlarca milyon kayıtlı en büyük zone’larda zone belleğe sığmıyor. 2022’de per-record build’ler full build’lerden ortalama 150 kat, bir milyon kayıtlı bir test zone’unda 4.250 kat hızlıydı ve yazı bir sonraki adımı zone ayarları için aynısını yapmak olarak bırakmıştı.

Neden ‘değişen ayarı yeniden build et’ demek yetmiyor? Bir kayıt olayı neyin değiştiğini söyler; bir zone olayı ise birçok Cloudflare ürününden gelebilir, zone’un neden değiştiğini söylemeyebilir ve aynı ada sahip birkaç zone’un ortak verisini değiştirebilir. Gereğinden fazla iş seçersen kapasite israf olur; gereğinden az seçersen edge’de eski ya da yanlış DNS verisi kalabilir. Örnek: Universal SSL’i açmak ya da kapatmak metadata’yı günceller ve zone apex’indeki (example.com gibi çıplak domain) CAA kayıtlarını değiştirebilir.

Çözüm: kanıtlanabilir en küçük build’i seçen bir planner ve aynı zone’un işlerini birleştiren yeni bir scheduler. Zone ayarı değişiklikleri artık onlarca milyon kayıtlı zone’ları yeniden build etmiyor. İkisi birlikte tepe bellek kullanımını yüzde 85 düşürdü ve açılan boşluk, pipeline’ın dayanıklılık için her zaman beklediği bazı bekleme sürelerini güvenle kısaltmaya izin verdi: bir DNS değişikliğinin Quicksilver’a yazılma süresi yarıya indi. Planner beş tür build arasından seçiyor: yalnızca belirli isimlerdeki kayıtlar (A, AAAA, TXT, CNAME değişiklikleri gibi), kayıtlar ve metadata (nameserver ve wildcard değişiklikleri), apex ve metadata (Universal SSL gibi ayarlar), purge (artık yayınlanmaması gereken zone’u kaldırma) ve kanıtlanamayan her durumda full zone.

Beş problem. Olayların neyin değiştiğini söylemesi gerekti: üretici, değişen alanları ve ayarları (mümkünse önceki ve yeni değerleriyle) olaya eklemeye başladı. Ama her olay o kadar belirgin değil: bazı veritabanı fonksiyonları yalnızca bir timestamp güncelleyip ‘zone hakkında bir şey değişti’ diyor ve bu bazen zararsız bir kayıt tutma, bazen başka yerde veri değiştiği anlamına geliyor. Çağıran tanımlanana kadar yalnızca timestamp’i değişen bir güncelleme full build tetiklemeye devam ediyor; eksik detay, bilinmeyen olay ya da zone’un herhangi bir yerindeki kaydı etkileyebilecek her değişiklik için aynı kural geçerli. Geri kalan problemler: her değişikliği en küçük doğru build’e eşlemek, aynı ada sahip tüm zone’ların paylaştığı veriyi hesaba katmak, olay ile build arasında veritabanının değişebilmesi ve işleri birleştirirken hiçbir Kafka mesajının kaybolmaması.