Recently I have been building a search engine as a microservice for a larger system I'm working on.

Yes, there are already excellent search engines available, but I saw it as an opportunity to learn how they actually work under the hood.

A few things I learned:

• Fuzzy search is significantly harder than exact matching.
• Supporting typos means you can't rely on simple database queries like ILIKE.
• Relevance ranking matters just as much as retrieval.

The engine currently uses:

• Levenshtein distance for typo tolerance
• TF-IDF based ranking
• An inverted index for retrieval

My first implementation used a Trie as the primary index structure.

On paper it looked perfect:

• Fast lookups
• Natural autocomplete support
• Simple prefix matching

Reality was different.

Once the index grew beyond ~100k documents, index build times became painful, memory usage exploded, and rebuilding the tree would stall the service. The latency was nowhere near where I wanted it to be.

So I switched to an inverted index.

That solved many of the scaling issues, but introduced new challenges:

• Prefix matching no longer comes for free
• Autocomplete requires additional structures
• Ranking becomes a separate concern

Then came the first serious stress test.

The results were... shit.

The service struggled.
The laptop struggled.
At one point the entire machine basically became unusable.

That was the point where the importance of data structures, indexing strategy, memory layout, and algorithmic tradeoffs became very real.

Building a search engine has given me a new appreciation for projects like:

• Meilisearch
• Elasticsearch
• OpenSearch

They make handling millions of records look easy, but there is a lot of engineering hidden behind that simplicity.

Current status:

• Fuzzy search
• TF-IDF ranking
• Inverted index
• Prefix search support
• Much better latency than the initial design

Still a lot to improve, but it's already been one of the most educational projects I've worked on.

Engine repo

Stress Test Performance Analysis

Report generated: 2026-06-02 15:27

Scale Achieved

• Virtual Users (VUs): Ramped successfully to 1,000 concurrent users
  • Minimum: 2
  • Maximum: 1,000
• Total Requests Processed: 9,914,382
• Sustained Request Rate: 8,697 requests/sec
• Test Duration: ~19 minutes

Data Transfer

Metric	Value
Data Received	8,367 MB (8.37 GB)
Receive Throughput	7.34 MB/s
Data Sent	921 MB
Send Throughput	0.81 MB/s
Total Data Transferred	~9.3 GB

Latency Performance

Metric	Value	Threshold	Status
Average Response Time	85.22 ms	—	—
Median (P50)	66.00 ms	< 10 ms	❌ Breached
P95	157.99 ms	< 50 ms	❌ Breached
P99	See raw metrics	< 100 ms	❌ Breached
Maximum	11,520 ms	—	Significant Spike

Reliability & Validation

Check	Result
HTTP 200 Responses	100% (9,914,382 / 9,914,382)
Valid JSON Content-Type	100% Pass
HTTP Request Failures	0%
Responses < 100 ms	74.79% Pass
Responses > 100 ms	25.21% (~2.5M Requests)

Summary

The system successfully sustained 8.7k requests/second while serving nearly 10 million requests under a 1,000 concurrent user load without a single HTTP failure.

While reliability remained excellent (100% successful responses), latency targets were not met:

• Median latency exceeded the target by 6.6×
• P95 latency exceeded the target by 3.2×
• Approximately 25% of requests took longer than 100 ms
• Maximum observed latency reached 11.5 seconds, indicating occasional tail-latency spikes under peak load

Key Takeaways

✅ No service failures

✅ No malformed responses

✅ Sustained high throughput

⚠️ Tail latency requires optimization

⚠️ P95/P99 response times remain the primary bottleneck

⚠️ Further indexing, caching, and query execution improvements are required before production-scale deployment