That sounds like a fun experiment—every millisecond counts when you’re chasing real‑time performance. Over the past few decades search engines have gone from simple inverted‑index files to a mix of clever data structures, compression tricks, and hybrid storage. In the early days a plain inverted list per term was the core: term → list of doc IDs, often stored on disk in a sorted, sequential format. As queries grew faster, engines started adding skip pointers to those lists so they could jump ahead without scanning every entry. Compression—like front‑coding or variable‑byte coding—kept those postings lists small, and the reduced I/O translated to speed. Around the mid‑2000s, index segmentation and sharding became standard. Each shard kept its own copy of the inverted index, allowing parallel query execution and better cache locality. The use of B‑trees or more recently, skip‑list based structures, let engines maintain sorted posting lists in a way that was efficient both for inserts and for reads. With the rise of semantic search, the index now often stores not only term → documents but also document embeddings and similarity vectors. Approximate nearest‑neighbor structures, like locality‑sensitive hashing or HNSW graphs, live alongside the classic inverted index. Now, for an in‑memory store like Redis, you can borrow several of these ideas: 1. **Skip pointers** – implement lightweight skip lists or index blocks inside the value field. Redis already uses a skip list for sorted sets, so you could adapt that to store postings lists, giving you O(log n) jumps within a list. 2. **Compression** – even though everything is in RAM, memory pressure matters. Techniques like delta‑encoding doc IDs or using roaring bitmaps for high‑density lists can reduce the memory footprint, letting you store more keys in the same space. 3. **Segmentation** – keep separate shards or hash buckets per term, so that queries can run on multiple workers in parallel. Redis Cluster already splits keys across nodes, but you could design the key pattern so that related postings live in the same slot. 4. **Hybrid storage** – keep a lightweight inverted index in memory for hot terms, and spill longer, less‑frequent lists to a secondary storage or even to Redis's LRU evictable space. 5. **Vector indices** – Redis has modules like Redisearch that already implement simple ANN structures. You could integrate an HNSW layer inside your data structure to handle semantic queries, just as modern search engines do. In short, the same concepts that made early search engines fast—sorted postings, skip pointers, compression, and sharding—translate well to an in‑memory environment. The trick is to pick the subset that gives you the most bang for your memory and CPU budget. Happy indexing!

That’s the right mindset—focus on the fundamentals and let the data drive the tweaks. I’ll be curious to hear how your jump logic ends up performing once you hit the real load. Good luck!

Sounds great, just hit me with the numbers when you’re ready and I’ll help you parse them. Happy bench‑testing!