Cloudflare перестроила конвейер распространения DNS-изменений, потому что полные пересборки крупных зон перестали масштабироваться. Zone Builder теперь получает около 700 изменений записей в секунду против 250 в 2022 году и ещё примерно 100 событий настроек. Отдельные зоны содержат более 20 млн записей и могут вырасти до сотен миллионов. Полная сборка читает, кодирует и сравнивает каждую запись, даже если в Quicksilver в итоге записывается лишь небольшое изменение.
Новый планировщик выбирает минимальный объём работы, безопасность которого можно доказать. Производители событий стали передавать изменённые поля и, где возможно, прежние и новые значения. Предусмотрены пять вариантов: обновление отдельных DNS-имён, имён вместе с метаданными, вершины зоны с метаданными, удаление зоны из публикации и полная пересборка. Ключевой критерий — каждый созданный точечной сборкой ключ Quicksilver должен побайтово совпадать с результатом полной сборки. Неизвестное или недостаточно описанное событие по-прежнему вызывает полную обработку.
Непосредственно перед выполнением система повторно читает актуальные настройки и состав публикуемых зон из реплик базы данных. Это нужно, потому что база могла измениться после события, а один домен иногда временно представлен несколькими внутренними зонами с общим ключом метаданных. Проверка отставания реплики не позволяет построить результат по устаревшим данным.
Единый scheduler объединяет работу по одной зоне, но не теряет подтверждения Kafka. Медленная сборка может завершиться не по порядку, однако committed offset двигается только после завершения всех предыдущих сообщений: при перезапуске Cloudflare предпочитает повторить работу, а не потерять изменение. Ограничение частоты пересборок не даёт одной активной зоне занять всех работников.
Корректность проверяли сравнением с полными сборками и зеркальным Zone Builder на производственных событиях. Он писал в отдельный Quicksilver без клиентского трафика, а comparer проверял 20% зон на лишние, отсутствующие и различающиеся ключи.
За сутки 92,95% сборок не требовали полной зоны; доля полных операций сократилась примерно на 40%. Средняя рабочая память упала с 49 до 7 ГиБ, пиковая — с 79 до 12 ГиБ. Максимальный всплеск p99 уменьшился с 14,6 до 1,21 минуты. Экономия ресурсов позволила сократить защитные интервалы ожидания и снизить медианную задержку записи в Quicksilver с 7,7 до 3,3 секунды. Последующее распространение по сети в эти измерения не входит.