Cloudflare تتوقف عن إعادة بناء DNS zone كاملة في 92.95% من عمليات البناء

نشر فريق Cloudflare في 2 نوفمبر 2026 مقالًا هندسيًا يقول فيه إن 92.95% من عمليات البناء لديه لم تعد تبني الـ DNS zone كاملة.

وكانت المشكلة أن أي تغيير في إعدادات zone كان يعيد بناءها بالكامل. وفي الـ zones الكبيرة التي تضم أكثر من 20 مليون record، كان ذلك بطيئًا ويستهلك كمية كبيرة من الذاكرة.

ولم يكن الحل تسريع البناء نفسه، بل تغيير السؤال. فبدل البحث عن طريقة لبناء كل شيء أسرع، بحث الفريق عن أصغر بناء يمكن إثبات أنه كافٍ. فأنشأ مكوّن تخطيط، أو planner، يصنّف كل حدث بحسب ما يمكن أن يؤثر فيه: هل يمس أسماء معيّنة، أم metadata مشتركة، أم قمة الـ zone. ثم يختار أصغر نوع بناء يعطي النتيجة نفسها التي يعطيها البناء الكامل.

والقاعدة التي تجعل ذلك آمنًا هي جوهر التصميم. فإذا كان الحدث غير واضح، أو تعذّر إثبات التساوي بين النتيجتين، يعود النظام إلى البناء الكامل. أي أن الافتراضي هو الخيار الأغلى والمضمون، والتحسين استثناء يجب إثباته في كل مرة.

وجاءت الأرقام بعد ذلك واضحة. فقد انخفض متوسط التأخير من نحو 7.7 ثانية إلى 3.3، وانخفضت أعلى قفزة في p99 من 14.6 دقيقة إلى 1.21 دقيقة، وتراجعت ذروة استهلاك الذاكرة من 79 إلى 12 جيجابايت.

ولا يرتبط هذا النمط بالـ DNS وحده. فأي مشروع يحمل cache أو index أو تقريرًا مبنيًا من بيانات يميل إلى إعادة بناء كل شيء، لأن ذلك الأسهل والأكثر أمانًا. وما يكشفه مقال Cloudflare أن العمل الحقيقي ليس في كود البناء، بل في القدرة على تصنيف التغيير وإثبات حدود أثره.