After the messaging rewrite, the next thing eating latency in our pricing platform was how we used Redis. We were moving to Redis 8 anyway, so I took the upgrade as a chance to rethink both the data we store and the way we talk to it. The result was roughly 2× lower Redis latency, ~20% faster price reindex, a knock-on ~20% on messaging, and a noticeably steadier environment.
First, the data itself. I reorganised what we keep in Redis — thinner records holding only the fields we actually read, instead of fat blobs carried around out of habit. Redis 8 ships a more stable JSON module, so I leaned on it for the structured entities. Smaller, well-typed documents mean less to serialise, less to move over the wire and less to scan.
On the search side, Redis 8's new INDEXMISSING and ismissing() syntax let me express null-checks properly in queries instead of working around them. I also moved one dependency — an entity that barely grows over time — out of the database and into persistent Redis, with a search index on top. It resolves in memory now, and the search support actually extended what we can do with it: richer, more flexible selects than we had before.
Then the access patterns, which is where a lot of quiet latency hides. Many small round-trips add up, so I batched reads and writes through MGET / MSET and pipelining wherever the shape allowed. Static reference data is now fetched in a single pipeline and held in a client-side cache, and independent searches run concurrently with tokio::join! instead of one after another. Fewer round-trips, more overlap.
That move paid off in a way I didn't plan for. With proper search on the Redis copy, three endpoint calls we used to fan out to collapsed into a single query — and it's faster on top of that, because it's Redis now instead of the database. Fewer network round-trips across the service, richer queries, lower latency. The cheapest request is still the one you never make.
Put together: ~2× lower Redis latency, ~20% faster reindex, fewer alerts. Redis 8's JSON and query improvements did real work here, but most of the gain came from storing less, asking for it in bigger batches, and not asking twice.