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.