Cache lookup
Every request checks Redis before executing the database search pipeline.
Final Search Architecture
Search once. Reuse the answer.
V5 wraps the complete indexed and typo-tolerant PostgreSQL search pipeline with Redis result caching. Cache hits bypass PostgreSQL entirely.
Try
R
Redis cache-aside search
Run a query once to populate Redis, then run the exact same logical query again to observe a cache hit and PostgreSQL bypass.
Search on miss
Cache misses continue through FTS + GIN and fuzzy fallback when necessary.
Reuse on hit
Cached search results can be returned without touching PostgreSQL.
Running final search pipeline
Checking Redis, PostgreSQL and active retrieval
strategy.
!
Search failed
Something went wrong.
QUERY
Search report
Normalized query
—
REDIS
Waiting
Cache status
This is the defining V5 decision point: return cached results or execute the search engine.
Run a query to inspect Redis behavior.
Time spent checking Redis.
Cache population time on a miss.
Configured cache lifetime.
Remaining lifetime for a cached result.
Versioned SHA-256 cache namespace.
CACHE-ASIDE
Request execution path
1
Normalize
query text
→
2
Redis GET
cache lookup
→
HIT?
YES
Return cached result
NO
Execute PostgreSQL
DATABASE
Waiting
PostgreSQL execution
Cache hits should show PostgreSQL as completely bypassed.
Waiting for request.
SEARCH STRATEGY
Waiting
Retrieval strategy
Original algorithm that produced these results.
PostgreSQL retrieval engine used on the cache-generating request.
Whether trigram fuzzy recovery was necessary.
PERFORMANCE
Timing breakdown
POSTGRESQL
Waiting
Execution report
Available when PostgreSQL executes.
⚡
PostgreSQL bypassed
Redis returned the cached search result, so no SQL query or EXPLAIN ANALYZE was executed.
Waiting for execution plan.
Raw SQL +
Raw EXPLAIN response +
ARCHITECTURE
Final SearchLab pipeline
01
↓
Query normalization
Lowercase + whitespace normalization
02
↓
Redis cache lookup
Cache-aside GET
03
↓
Full-Text Search
persisted tsvector + GIN
04
↓
Fuzzy fallback
pg_trgm similarity
05
↓
Redis SET + TTL
Store final search result
06
FastAPI response
Return results + diagnostics
BENCHMARK
V1 → V5
Evolution from raw substring search to cache-backed multi-stage retrieval.
| Version | Architecture | Results | App time | DB executed | Cache | Main improvement |
|---|---|---|---|---|---|---|
| V1 | ILIKE | — | — | Yes | None | Substring matching |
| V2 | Runtime FTS | — | — | Yes | None | Linguistic retrieval |
| V3 | FTS + GIN | — | — | Yes | None | Indexed retrieval |
| V4 | FTS + fuzzy | — | — | Yes | None | Typo recovery |
| V5 | Redis + V4 pipeline | — | — | — | — | Result reuse |
RESULTS
Search results
Results from the active search path.
0
shown
EXPLANATION
What changed in V5?
Cache-aside
Redis is checked before PostgreSQL. On a miss, the database result is stored for future requests.
GET → MISS → DB → SET
Database bypass
A cache hit returns the final result without executing FTS, fuzzy search or EXPLAIN.
database.executed = false
TTL
Cached results expire automatically so stale search responses do not persist indefinitely.
ex = 300
Graceful degradation
Redis is an optimization. If it fails, PostgreSQL remains the source of truth.
RedisError → PostgreSQL
Why Redis belongs after search quality and indexing +
Redis cannot improve relevance, fix poor fuzzy scoring or repair bad SQL. It only makes previously computed results cheaper to retrieve.
Linguistic retrieval.
Efficient candidate lookup.
Handle imperfect queries.
Avoid repeated computation.