Most teams adopt an in-memory data store for caching and stop there. They serialize complex objects into strings, ship bloated payloads across the network, and bolt on separate systems for queues, rate limiting, and leaderboards. More infrastructure, more latency, more cost.

This session walks through seven production use cases (Cache, Session Store, Message Queue, Leaderboard, Rate Limiter, Chat, and Real-time Streaming) and maps each to the Valkey data structure built for it. You'll see how Hashes replace serialized JSON blobs, how Sorted Sets power leaderboards without application-side sorting, and how Streams handle event-driven workloads that would otherwise need a dedicated message broker.

Using a live e-commerce application running on Kubernetes, I'll demonstrate how choosing the right data structure cut database spend by 55% with query caching and reduced LLM inference costs by 86% with semantic caching. You'll leave with a practical mental model: given a problem shape, pick the data structure, not the workaround.