Do the division first. Roughly 100 terabytes recovered across more than 250 billion entries is about 400 bytes per entry, or 440 if those terabytes are binary [1]. The cut was more than half, so the entry it started from sat under 900 bytes [2]. The savings the post itemises come out of the container rather than the records: a capacity word that will never be read, heap slots reserved for records that never arrive, and pointers that could have been offsets [7][8][12].
Units are load-bearing at this size. Eight bytes on each of eight fields is 64 bytes per entry [10], and 64 bytes times 250 billion entries is 1.6e13 bytes, which is 16 TB decimal and 14.6 TiB binary [3]. Cloudflare puts the fields-plus-heap-slack figure at over 15 terabytes [11], and that reconciles cleanly only on the binary reading [5]. Same bytes either way, but the label decides how many servers you think you got back.
The mechanism is three machine words. A `Vec<T>` carries a pointer, a length, and a capacity, and every push compares length against capacity to decide whether it must reallocate [6]. A cached DNS response is written once and then read until it expires [7]. The comparison never fires, the capacity is never consulted, and the growth room the `Vec` reserved on the heap is never filled: eight slots allocated, five records stored, three paid for and empty [8]. `Box<[T]>` and `Box<str>` are the same data with the growth machinery deleted [9]. The section merge is the same argument applied to indirection. Three separate lists mean three 8-byte pointers; one list with `u16` offsets costs 2 bytes per section, because a DNS section's record count fits in 16 bits [12].
The throughput and latency gains were measured on a synthetic fill: 56% A records, 25% AAAA, 19% TXT, one to four records per entry, with TXT randomised between 64 and 224 bytes to stand in for every variable-length type [13][14]. For those gains to appear in your cache, the insert path has to be dominated by allocator calls rather than parsing or socket work, and the entry has to be a scatter of small allocations rather than one packed buffer. It also has to be immutable after insert. That last condition is the one that disqualifies most people. If anything appends to a stored entry later, `Box<[T]>` is unavailable and the capacity word comes back.
The part I would copy is the instrumentation. Cloudflare wrapped Rust's `System` allocator to record the count and size of allocations per cache entry [15], which turns "this struct is fat" into a number you can regress against in CI. The post also says plainly that the synthetic inputs approximate production rather than reproduce it, that resident memory moves with traffic mix, cache occupancy, allocator state and memory outside the cache, and that resident memory was tracked across production instances during the rollout [16]. That step is what makes the 100 terabytes a measurement instead of a multiplication. The arithmetic behind the server analogy survives contact too: 100 TB over 130 Gen 13 machines is about 769 GB each [4], a plausible configuration rather than a flattering one.
