A Go and mmap playbook for p99 <1ms autocomplete on 240M records

Domain.garden founder Ruurtjan bypassed Elasticsearch for a custom Go solution using memory-mapped files and binary search, achieving sub-millisecond latency on a massive dataset with minimal complexity.

Ruurtjan, founder of domain.garden, needed to build an autocomplete search across 240 million domain names with a p99 latency under 1 millisecond. Instead of deploying a complex search stack like Elasticsearch, he built a custom Go service using a 4.5GB memory-mapped file. The founder reports this system achieves a p99 search time of 246 nanoseconds, excluding network overhead.

This is a playbook in trading flexibility for extreme performance, demonstrating how a precisely scoped problem can be solved with a fraction of the typical operational overhead.

Rejecting the standard search stack

The initial, conventional approaches failed. A simple PostgreSQL query using LIKE '%query%' was too slow for the interactive performance required by an autocomplete feature. The next logical step for many developers would be a dedicated search engine like Elasticsearch or Meilisearch.

Ruurtjan rejected this path, identifying it as overkill. The project required only simple prefix matching, not the complex full-text search, faceting, and aggregation features that justify the operational complexity and resource consumption of a full search engine. The goal was a minimal, fast, and cheap solution tailored to a single, well-defined problem.

Pre-sorting into a 4.5GB flat file

The foundation of the system is data preparation. All 240 million domain names were pre-processed and sorted alphabetically into a single, 4.5GB text file. Each domain is on its own line, separated by a newline character.

This offline, one-time-cost step is what enables the subsequent search algorithm to be so efficient. By enforcing a strict sort order on the entire dataset, the system can use more effective search methods than a linear scan. The data structure is the algorithm.

Memory-mapping the data for access

The core of the solution is a 4.5GB file containing all 240 million domain names, sorted alphabetically. Instead of reading this massive file into the application's memory, the service uses Go's mmap syscall. This function maps the file on disk directly into the application's virtual address space.

The operating system then handles loading pages of the file into physical RAM as they are accessed. This technique provides the application with slice-like access to the entire 4.5GB dataset without allocating corresponding heap memory, dramatically reducing the application's memory footprint and startup time.

Index jump then binary search

With the memory-mapped file in place, the search itself is a two-stage process. First, a tiny in-memory index maps the first letter of a domain ('a' through 'z') to its starting byte offset in the 4.5GB file. When a query like "founderr" arrives, the service immediately jumps to the offset for 'f'.

From that starting point, it performs a binary search within the relevant section of the file to locate the first entry that matches the prefix "founderr". Once found, the service simply reads the next 10-20 sequential lines from the file to return as results. This combination avoids a full dataset scan and leverages the pre-sorted nature of the data for a highly efficient lookup.

WHAT WE'D CHANGE

This architecture is a masterclass in optimization for a static dataset, but its strengths are also its weaknesses. The primary limitation is update inflexibility. To add or remove domains, the entire 4.5GB source file must be regenerated and sorted, followed by a service restart to load the new file. This is acceptable for data that changes monthly or quarterly but fails for any system requiring near real-time updates.

A second constraint is the single-node architecture. The solution is bound to the memory and I/O capacity of a single server. It cannot be scaled horizontally without significant re-architecture, such as sharding the dataset across multiple nodes. This creates a hard ceiling on traffic capacity and a single point of failure.

Finally, the query capability is purpose-built and brittle. The system excels at prefix matching (query%) but has zero capability for infix (%query%), suffix (%query), typo tolerance, or any other common search feature. Any expansion of product requirements beyond simple autocomplete would necessitate a complete rebuild, likely using the very tools this system was designed to avoid.

LANDING

This playbook is not a general replacement for Elasticsearch. It is a case study in precise, deliberate engineering. By constraining the problem to prefix-only search on a static dataset, the founder was able to build a solution that is orders of magnitude faster, cheaper, and simpler to operate than a general-purpose tool. It demonstrates a powerful principle: match the complexity of the solution to the defined complexity of the problem, not the imagined future possibilities. For many bootstrapped and indie projects, this is a winning trade-off.

The investor read

This is a classic 'built, not bought' engineering decision, signaling a founder with deep technical proficiency but a potential bias against standard tooling. For a niche product like domain.garden, this is a feature, keeping operational costs near zero. For a venture-backed SaaS, this could be a red flag. It represents a non-standard architecture that prioritizes raw performance over horizontal scalability and feature velocity. The play is investable as a micro-SaaS or developer tool, but would require a complete architectural rethink to become a platform-level enterprise service. It is a lifestyle business enabler, not a venture-scale foundation.

Pull quote: “The core of the solution is a 4.5GB file containing all 240 million domain names, sorted alphabetically.”