The Art of Instant: How to Build Lightning-Fast Domain Autocomplete

Ever typed something and had the suggestion appear before you even finished pressing the key? That's not magic—it's engineering. And it's a fascinating problem when you're working with 240 million domain names.

Why Speed Matters More Than You Think

When users type into a search box, they expect results immediately. Nielsen Norman Group established that 0.1 seconds is the threshold for users feeling like their actions are instantaneous. Anything slower, and the interface starts to feel sluggish—打断 the flow of exploration.

For a domain inspection tool like Wirewiki, the autocomplete is the main entry point. Every millisecond counts when you're trying to look up DNS records quickly. Users should feel like the tool is reading their mind, not waiting on a server.

The Prefetching Trick

Here's the beautiful part: the key insight isn't making the API faster (though that helps). It's about stealing time from the input process itself.

When a user presses a key (keyDown), you prefetch suggestions for what they're typing plus the next likely character. When they release the key (keyUp), you render whatever's ready. This means your time budget isn't the API latency—it's the duration of two key presses plus the gap between them.

On a 60Hz display, you have 16.7ms per frame. The budget works out to roughly 121ms for fast typists at p99. That's your window. Get results ready before the second key press ends, and to the user, it feels instantaneous.

Designing for Speed at Scale

The API needs to handle 240 million domain names without breaking a sweat. The clever approach here is treating popular domains differently from the long tail:

The Head: Top domains live in a character trie stored entirely in memory. Prefix lookups are just pointer walks—fast and predictable. The top 8 suggestions for every possible prefix are precomputed. Worst case? O(length of input). That's tiny.

The Tail: Everything else lives on an SSD with a memory-mapped block index. Domains are sorted, delta-compressed, and organized into fixed-size blocks with a small in-memory directory for binary search. The 240M domains take about 2.5GB, and the OS handles caching hot pages automatically.

Both structures have bounded inputs—the number of domains and query length don't grow unboundedly. This makes the effective complexity practically O(1), keeping p99 latency consistently low.

The Numbers Don't Lie

Stress testing revealed something interesting. The API itself answers most requests in under 2ms. Even under load at 1,600 requests per second, Nginx plus the API responds in 15ms at p99. Pretty solid.

But here's where reality intervenes: the network. In practice, end-to-end latency equals the round-trip time from browser through Cloudflare to your server, plus about 10ms overhead. For users in the same region as the server, you're within budget. For everyone else? That's where the asterisk appears.

The Asterisk

p99 0ms* means 99% of requests return results before the user finishes their key press, assuming they're near the server. Add 100-200ms of transatlantic latency, and suddenly you're over budget.

The fix would be geo-distributed servers with load balancing. But for a side project, that's a lot of infrastructure to maintain. Sometimes good enough really is good enough—especially when your target users are European developers checking domains.

What This Means for Your Next Project

There's a lesson here that applies far beyond domain lookups: prefetch intelligently. If you know what users might ask for next, fetch it before they ask. Let the UI react to what's ready rather than waiting for certainty.

The second lesson is about data structure choice. A trie for hot data, a well-indexed sorted structure for everything else. You don't need to keep 240 million items in RAM if you design your access patterns around what's actually likely to be requested.

Finally, measure your actual budget. In this case, two key presses plus a gap. What's your equivalent? Find it, optimize to it, and stop optimizing beyond it.

The result feels like magic. But it starts with understanding exactly how much time you actually have.