Implementing Search with Redis: A Backend Development Case Study

When backend developers face complex search requirements that cannot be satisfied efficiently with a single SQL query, they often resort to search engines like Elasticsearch, but this article explores how to implement the search logic entirely in-house using Redis as a cache and set operation engine.

Scenario : A shopping website needs to support six major categories of search filters, each containing sub‑filters with single‑choice, multi‑choice, or custom options. The final result set is the intersection of all selected filters.

Implementation 1 – Pure SQL : The first attempt writes a massive SQL statement with multiple LEFT JOINs and a final WHERE clause. The code (MySQL example) looks like:

select ... from table_1
left join table_2
left join table_3
left join (select ... from table_x where ...) tmp_1
... 
where ...
order by ...
limit m,n

While this works on a small test dataset, the query becomes unbearably slow on production‑scale data, leading to a performance failure.

Implementation 2 – Split Queries : The second approach breaks the giant query into several smaller ones, runs each separately, and intersects the result sets in application memory:

$result_1 = query('select ... from table_1 where ...');
$result_2 = query('select ... from table_2 where ...');
$result_3 = query('select ... from table_3 where ...');
... 
$result = array_intersect($result_1, $result_2, $result_3, ...);

This reduces the load on the database but still requires multiple round‑trips and does not meet the product manager’s speed expectations.

Implementation 3 – Redis Cache : The third solution introduces Redis to store the pre‑computed result IDs for each filter. Simple filters use Set structures; the price range filter uses a Sorted Set with the price as the score. Queries become set operations:

Single‑choice sub‑filter: SINTER or direct SMEMBERS on the corresponding key.

Multi‑choice sub‑filter: SUNION of the selected keys.

Final result: SINTER of all sub‑filter result sets.

For price ranges, the command ZRANGEBYSCORE retrieves the IDs whose scores fall within the desired interval.

Extension – Pagination : To paginate the final ordered result, the article stores the intersected IDs in a temporary Sorted Set (using ZINTERSTORE with the creation‑time score). The total pages are obtained with ZCOUNT, and page data with ZRANGE (or ZREVRANGE for descending order).

Performance Optimization : Because each Redis operation incurs a network round‑trip, the author recommends wrapping the series of commands in a transaction using MULTI and executing them atomically with EXEC. This reduces latency, though the transaction does not roll back on failure.

Summary : The demo shows that a Redis‑backed search can be far lighter than a full‑blown search engine, offering fast response times, easy set‑based logic, and extensibility for pagination and incremental updates, making it a practical pattern for backend developers handling complex e‑commerce search scenarios.