Redis 7.2 vs Memcached for session storage at 50k TPS

We're migrating our session layer from Memcached to Redis and I want to validate our approach before rolling out. Currently handling ~50k TPS across 3 nodes with Memcached, but we need persistence + better data structures.

Current setup:

• Memcached 1.6.20 on 3x Vultr bare metal boxes
• ~2GB session data, avg TTL 30min
• 85% hit rate, p99 latency 2.5ms

Proposed:

• Redis 7.2 cluster with persistence (RDB + AOF)
• Same 3-node layout
• Hashes instead of serialized strings

Does this seem reasonable? Any gotchas with Redis AOF at this scale? Also considering Contabo's managed Redis but want to keep it in-house for now.

At 50k TPS, watch your AOF rewrite cycles—they can tank latency spikes if you're not careful. Consider auto-aof-rewrite-percentage 100 and run rewrites during off-peak. Also, with 3 nodes, Redis Cluster's slot migration overhead might bite you; I'd benchmark against standalone sentinels first. Hashes are smart but verify your serialization overhead doesn't negate the persistence gains. Check the Redis tuning docs: https://redis.io/docs/

Good point on AOF rewrites—I wasn't thinking about off-peak timing. We do have a predictable traffic dip around 2-4am UTC so we can schedule it then. Quick follow-up: should we disable AOF entirely and just rely on RDB snapshots, or is the dual persistence worth the overhead at our throughput?

Don't disable AOF entirely—you'll lose the durability you're gaining. Better approach: use appendfsync everysec instead of always, and enable aof-use-rdb-preamble yes in 7.2. This hybrid format loads way faster on restart and reduces rewrite frequency by ~60%. Also benchmark your 3-node cluster under load first; at 50k TPS you might hit network saturation before CPU becomes an issue. https://redis.io/docs/

One thing nobody mentioned yet: at 50k TPS, your network throughput matters just as much as latency. Redis hashes will reduce payload size vs serialized strings, but validate your NIC bandwidth first—3 nodes at that scale can saturate 1GbE easy. Also consider client-output-buffer-limit tuning; defaults will OOM you under sustained load. https://redis.io/docs/ has good guidance on this.

been running Redis 7.2 at similar scale, hashes definitely helped but honestly the real win was tuning client-side connection pooling—saved us more latency than any config change