Implementing Pagination and Multi‑Condition Fuzzy Search in Redis

Introduction

Redis provides high‑performance in‑memory storage with data types such as String, List, Set, SortedSet and Hash. It supports exact key lookups but does not offer SQL‑like fuzzy or conditional queries. When hot data resides in Redis and the use case requires pagination, sorting, and flexible filtering (e.g., comments, timelines), a custom design is required.

Pagination with Sorted Sets

Sorted Sets (ZSet) store ordered members. ZADD key score member […] adds a member with a numeric score that determines order; timestamps are commonly used as scores. ZREVRANGE key start stop returns a range of members and serves as the core pagination operation. ZREM key member removes a member, supporting delete‑comment scenarios. Because ZSet maintains order and can filter by score, it is generally more suitable for pagination than List, which lacks automatic sorting.

Fuzzy Multi‑Condition Query with Hashes

Each record is stored as a Hash field whose name encodes searchable attributes, e.g. <id>:<name>:<gender>, with the JSON representation of the object as the value. HSCAN hash_key MATCH pattern COUNT n iterates over all fields and supports pattern matching; for example *:*:female finds all female users. Matching fields are collected into a temporary Set or List, which can then be used to retrieve the corresponding values.

Combined Pagination and Fuzzy Search

Define a query pattern (e.g. *:*:male or 100*:*:*).

Check whether a ZSet keyed by this pattern already exists.

If not, run HSCAN with the pattern, collect matching keys, and create a new ZSet where each member’s score is derived from the original data (e.g., timestamp).

Store the new ZSet with an expiration time.

If the ZSet exists, apply ZREVRANGE directly to obtain the required page.

This workflow reuses the pagination logic while providing flexible fuzzy filtering.

Performance Optimizations

Generating a ZSet for every distinct pattern can exhaust cache space. Assign a TTL (time‑to‑live) to each generated ZSet so that unused sets expire automatically; when a set is accessed, its TTL is refreshed.

Two strategies for keeping the ZSet up‑to‑date are discussed:

On each Hash insertion, also insert the new member into any relevant ZSets (requires tracking which patterns apply).

Periodically rebuild the ZSet, which is simpler but may produce stale pagination results.

The choice depends on real‑time requirements and cache pressure.

Conclusion

The design achieves pagination and multi‑condition fuzzy search in Redis without code, outlines the essential Redis commands, compares Sorted Set versus List for pagination, and presents cache‑friendly optimization techniques.