ValkeyConf 2026

After a Booking.com accommodation reservation, our post-booking service caches reconstructible reservation and order data for web/mobile journeys. To retire self-managed Redis OSS, we first used ElastiCache for Valkey with cluster mode disabled, retained Jedis to limit scope, and routed reads/writes to the primary for read-after-write consistency. At 10% traffic, cache-read p99 rose ~5→15 ms; at 50%, it reached ~50 ms with ~100 ms spikes, and service-latency compliance fell to ~97%, breaching its 99% SLO. Valkey execution remained 20–30 μs, shifting our investigation beyond the engine.

We then enabled a one-shard, three-AZ cluster and moved to Lettuce 6.6.0 with adaptive and 60-second periodic topology refresh and lowest-latency reads across primary and replicas. We accepted eventual consistency for this reconstructible cache; writes remained primary-routed. These changes cut cache-read p99 ~50→3 ms (~94%), but GraphQL p99 remained ~800 versus ~600 ms. Lock telemetry exposed retry waves and redundant loads; retry jitter and cache rechecks cut contended-lock p99 by ~70% and restored GraphQL p99 to ~610 ms, near its ~600 ms pre-migration baseline, completing the migration.

LLMs can write code, answer questions, and execute tasks, but they have one major limitation: they forget. Every new conversation starts from scratch unless we explicitly build systems that preserve context, state, and memory.

In this talk, we'll explore what it actually takes to give AI agents memory. Rather than focusing on prompts or models, we'll focus on the infrastructure layer that sits behind them. We'll examine common memory patterns used in agentic systems, including conversation history, session state, semantic caching, user preferences, and long-term knowledge retrieval.

Using Valkey as the foundation, we'll discuss design decisions, trade-offs, and operational challenges such as memory growth, retrieval latency, cache invalidation, and observability. We'll also look at how memory architectures impact both response quality and inference costs.

The goal is not to build another chatbot. The goal is to understand how stateful AI systems are engineered and why memory is becoming one of the most important infrastructure problems in modern AI.

Agent workloads make a lot of LLM calls. A surprising number of them are redundant. Every call you serve from cache is latency and money you don't pay for.

There is no single cache, but a stack, and Valkey can fit at every level - from the cheap and brittle to the smart and careful. Exact-match response caching on vanilla Valkey. Embedding caches, the layer most people forget, which saves you from paying to vectorize the same text. Then semantic caching with valkey-search, for queries that mean the same thing but don't match byte-for-byte.

I go deep on semantic because it is where most production setups quietly break. The usual setup is one global similarity threshold for everything, and it can't win: set it loose and you serve confident wrong answers, tighten it and your hit rate collapses to almost nothing, and the worst part is you can't tell which until someone complains about a bad response in production. I will show why, and what works instead: per-category thresholds, confidence bands, and how to check a hit is correct before you trust it.

You don't need to know LLMs to follow along. You will leave knowing which cache solves which problem, and where Valkey fits in each.