The number that has to hold is 121 milliseconds [5], and the server already eats some of it. At 1,600 requests per second Pul reported a p99 of 15 ms for Nginx and the API together [15], leaving roughly 106 ms for DNS, TLS, Cloudflare and the wire [20]. Most API-only requests finished inside 2 ms [14], so the wire, not the application, is the thing under test.
That budget is one person's hand. Pul measured it typing 100 domain names at a pace he called reasonably fast [5]. It transfers only under two conditions. Your users have to type in bursts, because the window is defined between one keydown and the following keyup [2][3], and a keystroke with no successor has nothing to hide the fetch behind [25]. And they have to sit near the box.
The part I would actually copy is the index. The head is an in-memory character trie holding eight precomputed suggestions per prefix, seeded from Tranco's ranking of one million popular domains [8]. The tail is a sorted, delta-compressed file on SSD reached through memory mapping, with a 27 MB in-memory directory addressing fixed blocks of 256 names, so a lookup is one binary search followed by a short linear scan [9]. All 240 million names occupy about 2.5 GB on disk [10]. That works out to roughly 10.4 bytes per name [21], and the directory to about 29 bytes per block entry [22]. Sorting and delta coding do that, not a clever database. It is the least quotable part of the writeup.
The corpus has a contractual shape too. Most of the extra names come from ICANN's Centralized Zone Data Service, which covers participating generic top-level domains, while country-code domains carry no equivalent access requirement and leave gaps that Tranco only partly fills [11].
Then the benchmark. The stress test was LLM-generated: 720,000 keystroke queries synthesised from 60,000 typed domain names [13], which is 12 keystrokes per name [23]. It was replayed at fixed rates against the API, the Nginx origin and the full Cloudflare route [13]. A fixed-rate replay measures throughput, but it strips out the human think time the whole design depends on, so it cannot measure the keystroke window itself. The 1,000-simultaneous-typists run stayed inside his local budget [16], and all of these are Pul's production measurements rather than an independent test [17].
The claim runs out at the border, though. Pul says US traffic can add 100 to 200 ms [18]. The low end consumes 83% of the 121 ms window, and the high end overruns it by 79 ms [24]. He knows, and wrote the asterisk himself: in a June 22 post on X he said multi-region routing "would give me the p99 0 ms* latency. But that's a bit much. Even for me." [19]
I read the whole thing as the right order of operations for my context, which is a single-region audience and a corpus that changes daily rather than per user. Optimise the code path until the network dominates, then decide separately whether the network is worth buying. Pul stopped at that line and said where it was, which is more than most latency posts manage.
