Home › Scenarios › Search typeahead
System design scenario
Design search typeahead (autocomplete)
Intermediate
Suggestions must appear while the user types: a tight p99 at half a million lookups per second, against an index with long-tail latency.
▶ Simulate this designThe goal
Keep p99 < 50 ms and error rate < 0.10% at 500,000 req/s for 10s.
- Peak load
- 500,000 requests per second
- Traffic mix
- 100% reads, 0% writes
- p99 latency
- under 50 ms
- Error rate
- under 0.10%
The starting architecture
The simulator opens with this design. It is deliberately too weak for the goal: run it and watch which component saturates first.
- Edge LB (Load Balancer, 2 instances): Edge load balancer for suggestion requests.
- Suggest service (Service, 80 instances): Suggest service: normalises the prefix and returns the top completions.
- Search index (Database): Search index with a long latency tail (σ = 0.6). Any request that reaches it risks the p99.
How to approach it
The hints unlock one at a time in the app. Try the design yourself before reading them.
Show the hints
- Prefixes repeat enormously: cache the top suggestions per prefix.
- The index has a fat tail (σ = 0.6): any request that reaches it is likely to blow the p99.
- Aim for a hit ratio above 99% so index lookups fall outside the slowest 1%.
What the simulator shows you
SimLoad models every component as a queue with real capacity, latency, timeouts and retries, so you see utilisation, p50/p99 latency, errors and monthly cost change as you scale. Insights name the bottleneck in plain language, and the capacity planner sizes the fix. A reference solution that meets the goal is verified by automated tests.
▶ Try it in the simulator