Autocomplete 240 triệu tên miền với độ trễ p99 0 ms — Bí quyết kỹ thuật đằng sau Wirewiki

Wirewiki, một trang web chuyên kiểm tra hạ tầng internet như DNS, delegation và cấu hình email, vừa gây chú ý trong cộng đồng công nghệ khi công bố kỹ thuật giúp tính năng autocomplete tên miền phản hồi gần như tức thì — với độ trễ p99 chỉ 0 ms. Bí quyết nằm ở việc prefetch dữ liệu ngay từ thời điểm người dùng nhấn phím, thay vì chờ đến khi họ gõ xong từ khóa.

Thay vì tối ưu hóa API đến mức tối thượng, Ruurtjan — nhà sáng lập Wirewiki — tập trung vào việc tận dụng thời gian giữa các lần gõ phím để tải trước kết quả. Điều này cho phép giao diện hiển thị gợi ý trong "khung hình tiếp theo" (16.7 ms) mà người dùng không cảm nhận được độ trễ.

Bí quyết nằm ở "khung thời gian" giữa các lần gõ phím

Ruurtjan định nghĩa lại bài toán: thay vì đo độ trễ API, ông đo độ trễ từ lúc nhả phím đến lúc kết quả sẵn sàng để render. Với một người gõ nhanh, thời gian trung bình giữa hai lần nhấn phím là khoảng 121 ms (p99). Nếu API trả về trong khoảng thời gian đó, người dùng sẽ thấy kết quả ngay khi họ bắt đầu gõ ký tự tiếp theo.

Cụ thể, khi người dùng nhấn phím 'i' (trong từ khóa "wiki"), giao diện ngay lập tức gửi yêu cầu GET /autocomplete?q=wi. Nếu phản hồi đến trước khi họ nhả phím 'k', kết quả cho "wik" sẽ hiện ra mà không có bất kỳ độ trễ cảm nhận nào.

Kiến trúc API hai tầng: Trie + Memory-mapped Index

Để đạt tốc độ này, Wirewiki sử dụng hai nguồn dữ liệu chính: Tranco list (top 1 triệu tên miền phổ biến) và CZDS (danh sách toàn bộ tên miền từ các gTLD như .com, .net, .org). Tổng cộng khoảng 240 triệu tên miền.

• Head (phần đầu): Một character trie (cây tiền tố) được lưu trong bộ nhớ, với 8 gợi ý phổ biến nhất được tính sẵn cho mọi tiền tố. Tra cứu chỉ là vài bước đi qua con trỏ — độ phức tạp O(chiều dài từ khóa).
• Tail (phần đuôi): Một block index được memory-map trên SSD. Dữ liệu CZDS được sắp xếp, nén delta thành các block cố định (256 tên mỗi block). Thư mục nhỏ (27 MB) nằm trong RAM, giúp binary search nhanh chóng. Toàn bộ 240 triệu tên miền chỉ chiếm 2.5 GB dung lượng đĩa.

Nhờ giới hạn cả chiều dài truy vấn lẫn số lượng tên miền, độ phức tạp trường hợp xấu nhất của cả hai cấu trúc là O(1) — giữ p99 latency ở mức thấp ổn định.

Kết quả kiểm tra tải: Ấn tượng dù chỉ có một máy chủ

Ruurtjan đã dùng LLM để stress test server sản xuất với 720,000 truy vấn mô phỏng từ 60,000 tên miền. Kết quả:

• API thuần túy: Hầu hết phản hồi dưới 2 ms.
• Qua Nginx (origin path): p99 là 15 ms ngay cả ở tốc độ 1,600 req/s.
• End-to-end qua Cloudflare: Độ trễ xấp xỉ bằng round-trip time + 10 ms — vẫn nằm trong "ngân sách" 121 ms.

Dù vậy, Wirewiki chỉ đang chạy một máy chủ duy nhất tại châu Âu. Với người dùng ở Mỹ, độ trễ có thể tăng thêm 100-200 ms, vượt ngân sách p99. Ruurtjan thừa nhận nếu muốn mở rộng toàn cầu, cần thiết lập đa máy chủ và geo load balancing — nhưng ông cho rằng sản phẩm này quá ngách để xây dựng thành doanh nghiệp. Tuy nhiên, ông để ngỏ khả năng: "Email tôi nếu bạn sẵn sàng trả phí để truy cập API này, tôi có thể đổi ý."

Bài học cho nhà phát triển Việt Nam

Với cộng đồng lập trình viên trong nước, câu chuyện này mang lại hai bài học quan trọng:

• Tối ưu trải nghiệm thay vì chỉ tối ưu API: Đôi khi giải pháp tốt nhất không nằm ở việc làm cho server nhanh hơn, mà là thông minh hơn — tận dụng thời gian "chết" của người dùng để prefetch. Đây là tư duy thiết kế sản phẩm đáng học hỏi, đặc biệt với các ứng dụng web cần tốc độ cao.
• Cấu trúc dữ liệu vẫn là vua: Việc kết hợp trie (bộ nhớ) + memory-mapped index (SSD) cho phép xử lý hàng trăm triệu bản ghi với chi phí phần cứng khiêm tốn. Đây là mô hình khả thi cho các startup Việt Nam muốn xây dựng dịch vụ tra cứu dữ liệu lớn với ngân sách hạn chế.

Nếu bạn muốn trải nghiệm thử, hãy ghé thăm Wirewiki.com và thử gõ vài tên miền — bạn sẽ thấy sự khác biệt rõ rệt giữa "nhanh" và "tức thì".