Cloudflare memperbarui DNS Zone Builder agar tidak lagi membangun ulang seluruh zona setiap kali ada perubahan kecil. Dalam tulisan teknis yang terbit 2 November 2026, perusahaan itu mengatakan pendekatan baru memangkas penggunaan memori hingga 85 persen dan kira-kira membagi dua waktu dari perubahan DNS sampai datanya ditulis ke Quicksilver, sistem penyebaran konfigurasi internal Cloudflare.

Perubahan ini menyasar masalah yang tidak terlalu terlihat dari luar: pekerjaan berlebih di balik propagasi DNS. Ketika sebuah catatan berubah, sistem lama tetap perlu membaca seluruh zona, mengubahnya ke format yang dipakai di edge, lalu membandingkan hasilnya dengan data yang sudah ada. Cara itu masih masuk akal untuk zona kecil. Namun, Cloudflare mengatakan beberapa zona terbesar kini memiliki lebih dari 20 juta catatan dan diperkirakan akan terus tumbuh hingga ratusan juta.

Beban tersebut makin terasa karena Zone Builder memproses lebih banyak peristiwa. Pada 2022, komponen itu menerima sekitar 250 perubahan catatan DNS per detik. Angkanya kini mendekati 700, ditambah sekitar 100 jenis peristiwa lain seperti perubahan pengaturan zona. Masalah utamanya bukan sekadar jumlah peristiwa, melainkan jenis pekerjaan yang dipicu tiap peristiwa dan ukuran zona yang harus dibaca.

Dari full build ke targeted build

Cloudflare menyebut pendekatan barunya sebagai targeted build. Alih-alih menganggap semua perubahan sama, sistem membaca peristiwa yang masuk untuk menentukan bagian DNS yang mungkin terdampak. Pengumpul peristiwa DNS menggabungkan pesan dari beberapa topik Kafka, kemudian Zone Builder mengubahnya menjadi pekerjaan yang lebih spesifik.

Perubahan A, AAAA, TXT, atau CNAME biasa, misalnya, umumnya hanya membutuhkan pembangunan ulang catatan pada nama DNS tertentu. Perubahan nameserver atau wildcard juga perlu memperbarui metadata bersama. Pengaturan seperti Universal SSL dapat memengaruhi catatan CAA di apex zona, sehingga masuk ke jalur yang berbeda. Untuk keadaan tertentu, sistem tetap menjalankan full-zone build. Ada pula jalur purge untuk menghapus zona yang tidak lagi dipublikasikan.

Pembagian ini bukan sekadar optimasi yang boleh menghasilkan jawaban “hampir sama”. Aturan Cloudflare jauh lebih ketat: setiap kunci yang ditulis oleh targeted build harus identik byte demi byte dengan kunci yang akan dihasilkan oleh full build. Jika sistem tidak bisa membuktikan dampak suatu perubahan, ia tidak menebak. Ketidakpastian dinaikkan menjadi pekerjaan penuh.

Aturan itu penting karena event tidak selalu menjelaskan semuanya. Sebuah pembaruan timestamp bisa berarti hanya pencatatan administratif, tetapi pada kasus lain menandai perubahan data yang terjadi di tempat berbeda. Event yang kehilangan detail, event yang tidak dikenal, atau perubahan yang mungkin memengaruhi catatan di mana pun tetap memicu full build.

Data bisa berubah setelah event datang

Cloudflare juga harus menghadapi jeda antara event dan eksekusinya. Database bisa berubah setelah event dibuat, sementara event itu sendiri sudah tiba di konsumen Kafka. Karena itu, Zone Builder merencanakan pekerjaan dua kali: pertama dari event yang masuk, lalu sekali lagi dari snapshot publikasi terbaru sesaat sebelum eksekusi.

Pembacaan terakhir dilakukan dari replika read-only. Cloudflare menyebut Kafka dan replikasi database berjalan secara independen, sehingga event bisa datang sebelum perubahan terkait terlihat di replika. Pengumpul DNS menunda event untuk menutup jeda normal, kemudian pemeriksaan database terakhir menolak pembacaan apabila replika masih tertinggal.

Snapshot segar itu dapat mengubah keputusan. Targeted build bisa dinaikkan menjadi full build jika keadaan zona kini memerlukannya. Pekerjaan bisa berubah menjadi purge jika zona tidak lagi boleh dipublikasikan ke jaringan tersebut. Pembangunan juga dapat dilewati jika zona pemicu sudah tidak termasuk dalam metadata bersama.

Menghindari satu zona menahan semuanya

Sebelumnya, pekerjaan record dan full-zone memakai scheduler yang berbeda. Cloudflare menggantinya dengan scheduler terpadu yang dapat menggabungkan beberapa event sebelum build dimulai. Perubahan A record pada www.example.com dan perubahan wildcard, misalnya, digabung sebagai satu pekerjaan dengan daftar nama dan pembaruan metadata yang sesuai.

Scheduler tetap memisahkan pekerjaan DNS dari pesan Kafka yang menunggu pengakuan. Retry mempertahankan keduanya. Ini mencegah sistem menganggap pesan selesai hanya karena sebagian pekerjaan sudah berhasil.

Alasannya berkaitan dengan cara Kafka menyimpan offset. Offset yang maju melewati pekerjaan yang belum selesai dapat membuat perubahan pelanggan hilang setelah restart. Cloudflare memilih mengulang pekerjaan daripada mengambil risiko itu. Build yang selesai tidak berurutan boleh ditandai selesai di memori, tetapi offset baru benar-benar maju setelah semua pesan sebelumnya juga aman.

Untuk zona terbesar, full build bahkan bisa tidak selesai karena seluruh data dan kunci Quicksilver tidak muat dalam memori. Di atas ambang jumlah catatan tertentu, Zone Builder tidak mengeskalasi pekerjaan menjadi full build. Ia membangun apex, metadata, dan nama-nama yang diidentifikasi event yang sedang antre. Cloudflare mengakui ini sebagai trade-off, tetapi full build yang tidak pernah selesai akan menahan perubahan lain pada partisi Kafka.

Memastikan hasil tetap sama

Cloudflare menguji targeted build terhadap full build dari keadaan database yang sama. Pengujian mencakup jalur nameserver, wildcard, dan apex, dengan nilai yang bergantung pada waktu dibuat tetap agar setiap kunci bisa dibandingkan byte demi byte.

Sebelum peluncuran, perusahaan juga menjalankan full build di samping targeted build dan membandingkan keluarannya. Kini ada mirror Zone Builder yang mengonsumsi aliran Kafka produksi serta membaca keadaan database produksi, tetapi menulis ke lingkungan Quicksilver terpisah yang tidak melayani trafik pelanggan.

Perbaikan ini tidak membuat seluruh full build hilang. Penerbitan zona untuk pertama kali, perubahan yang dapat memengaruhi catatan di mana pun, dan keadaan yang tidak cukup jelas masih membutuhkan pekerjaan lengkap. Namun, beban terbesar sudah dipindahkan: perubahan yang sebelumnya memaksa zona dengan puluhan juta catatan dibaca dari awal kini dapat berhenti pada bagian yang benar-benar terdampak.

Sumber Cloudflare, “How we halved DNS build delay and cut memory use by 85%”, 2 November 2026. Sumber tambahan dan konteks dalam artikel ini berasal dari penjelasan teknis Cloudflare tentang Kafka, Quicksilver, replika database, dan pengujian equivalence pada tulisan yang sama.