Search Autocomplete: Junior → Architect Evolution
The mandated interactive flow. Step through each rung, ask what breaks FIRST, weigh the options, and defend the chosen architecture. This is how architectural thinking is learned — not by reading a fixed design, but by tracing how it evolves under growth pressure.
Scale Evolution Timeline
Step through 6 architectural rungs, from 10K RPS to 1B RPS. At each rung, ask: what will break FIRST? Why? What options exist? Which one do we pick — and what are we accepting?
This is the reasoning cycle that separates a Junior developer ("here's an architecture") from an Architect ("here's why this architecture, why now, and what breaks next").
10K RPS — Redis sorted set + client debouncing
1. Current architecture
Where we are before growth pressure
3 apps + Redis (sorted set per prefix with pre-computed top-K). Client debounces 300ms per keystroke. Nightly Spark batch job walks yesterday's query logs, precomputes prefix→top-K, blue-green swap to Redis.
2. Growth trigger
What changed — the traffic/data force
MVP. 100K users typing search queries. Peak 10K autocomplete requests/sec (mostly from typing). Corpus: 1M distinct queries.
3. Bottleneck — what breaks FIRST?
The component that saturates as growth arrives
None yet — Redis sorted sets work at MVP
Redis ZRANGE per prefix = sub-ms. 1M prefixes × 10 top-K each = 10M keys × 100 bytes = 1 GB (fits in Redis easily). Nightly rebuild is fine — trending events aren't yet a concern. p99: 3-8ms server-side.
Redis memory 1 GB, ZRANGE latency 0.5ms, server p99 8ms, browser debounce reduces load 60%
4. Options — what could we do?
Alternatives an architect must consider before picking
- + Simplest possible architecture
- + Sub-ms Redis latency
- + Blue-green swap = zero downtime rebuild
- + Team already knows Redis
- − No trending events (nightly rebuild only)
- − No fuzzy match without prefix expansion (expensive)
- − Memory grows with distinct queries
5. Chosen
The specific decision we're making
Do nothing — Redis sorted sets are right at 10K RPS
6. Trade-offs
What we're explicitly accepting to move forward
- Accept no real-time trending (nightly rebuild)
- Accept no fuzzy match (typo tolerance)
- Accept memory linear with corpus size
7. New architecture
The system after this decision — headroom for the next 5-10x
3 apps + Redis + nightly Spark rebuild. Total cost: $500/mo.
8. Next bottleneck — what will break at the NEXT rung?
This is the seed of the next rung
At ~100K RPS with 100M distinct queries + typo tolerance demand, Redis sorted sets become memory-heavy + no fuzzy. FST (Lucene) is 5-10x smaller + supports fuzzy. L5 shape.
What comes next in your Junior → Architect journey
You've traced 6 rungs of Search Autocomplete evolution. Now try the same reasoning cycle on a system you don't know yet — pick from the Systems catalog and answer the same questions: current arch → growth trigger → bottleneck → options → chosen → trade-offs → new arch → next bottleneck. That is architecture.