Ishan Jain
Software Engineer 2
Actions
Ishan Jain works as an SRE at Mastercard, with a passion for building reliable systems at scale. A maintainer of the Valkey Helm charts under the Linux Foundation, a Docker Captain and an AWS Community Builder, he speaks on topics including Kubernetes, AWS, Valkey, GitOps, observability and AI infrastructure. Having found his way into tech without a roadmap, he writes and speaks to help others find theirs. Outside of work, he’s a specialty coffee nerd who brews on an AeroPress or V60 and never says no to a board game night.
Agents Are a Cache Problem: Sharing KV Across vLLM Replicas With Valkey
Agent turns are mostly prefix: system prompts, tool schemas, prior turns, retrieved context. In a twenty-step loop, recomputing that prefix every time dominates latency.
For an 8B model with GQA, 32 layers, 8 KV heads, 128-dimensional heads, and FP16 KV cache, a 10,000-token prefix is about 1.2 GiB of KV state. vLLM reuses it within a replica. Then you autoscale behind Kubernetes, consecutive turns land on different pods, hit rates fall, dashboards stay green, and p99 TTFT quietly doubles.
This talk walks through what is happening under the hood: where KV blocks live across HBM, host DRAM, and a remote tier, how LMCache moves them through a RESP backend, and how Valkey acts as the shared cache. Plus the bandwidth math for a practical question: when is moving 1 GB of KV state faster than recomputing it on an H100?
Then the security issue we did not expect. Because blocks are content-addressed, two tenants with the same system prompt share cache entries by default. We show the isolation risk and how we closed it with Valkey database namespaces and database-level ACLs.
You leave with a working config, benchmark methodology, and the failure modes we hit first.
Caching Fire: Running Valkey on Kubernetes
Modern applications demand low latency, high throughput, and reliable data access, making caching a critical part of cloud-native architectures. But running a distributed cache in production brings its own challenges, from scaling and upgrades to failovers and operational complexity.
In this session, we'll explore how to run Valkey on Kubernetes using the Valkey Operator and the Valkey Operator Helm Chart. We'll look at how Kubernetes operators simplify the lifecycle management of stateful services and enable platform teams to automate common operational tasks.
Through live demonstrations and real-world examples, we'll cover deploying Valkey clusters, scaling workloads, performing upgrades, handling failures, and exposing metrics for observability. We'll also discuss the architectural tradeoffs and operational considerations involved in running cache infrastructure in production Kubernetes environments.
Whether you're a platform engineer, SRE, developer, or cloud-native enthusiast, you'll leave with a practical understanding of how Kubernetes and the Valkey Operator can help build resilient, scalable, and production-ready caching platforms.
Breaking Charts: What I Learned Maintaining valkey-helm
Valkey started with one Helm chart. It's becoming three, and the reasons why trace a line straight through how Valkey actually runs.
Valkey has two deployment modes, and they pull in different directions. Standalone (with Sentinel likely down the road) is served by valkey-helm: pods, services, config, no controller needed. Cluster mode is a different beast, sharded and coordinated, and that's where valkey-operator comes in, managing Valkey through CRDs. valkey-resources, currently in design, would ship just the custom resources for a cluster-mode setup, assuming the operator already lives in the cluster. Three charts, drawn along the seam between standalone and cluster.
This talk uses that split to open up how a maintainer team works. Why cluster mode earns an operator when standalone doesn't. Why we'd ship CRs as a separate chart instead of folding them into the operator. How we argue about naming and scope in public GitHub discussions, and how we weigh backward compatibility against a cleaner design. You'll see what breaks when a chart assumes a controller exists, how the operator-first-then-resources dependency shapes UX and failure modes, and how we decide what belongs in which layer.
If you build internal platforms or maintain Helm charts, you'll leave with a sharper model for splitting responsibilities along the grain of how software actually runs, and a look at how open source design gets argued out in the open.
KCD Gujarat 2026 Sessionize Event
Cloud Native Group Noida User group Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top