Redis : Small Change, Big Architectural Impact

Whenever someone talks about cache, 90% of us immediately think about Redis. It has been around since 2009 and has powered everything from session stores, rate limiters to full-blown distributed coordination systems. Why??? because it’s fast, simple and battle-tested.

Most of us have used the Redis “TTL” feature, you set the expiry on the key and forget about it. Cleanup happens automatically. No cron jobs, no background workers, no scheduler logic.

SET <KEY-NAME> <VALUE> EX <TIME-IN-SECONDS>

Redis keys are expired in two ways: a passive way and an active way.

A key is passively expired when a client tries to access it and the key is timed out.

However, this is not enough as there are expired keys that will never be accessed again. These keys should be expired anyway, so periodically, Redis tests a few keys at random amongst the set of keys with an expiration. All the keys that are already expired are deleted from the keyspace.

14 Years of Key-Level TTL

Redis introduced the hash data structure in 2010. From that point onward, hashes became the natural way to model structured data inside Redis — user’s state, feature flags, counters etc.

For more than 14 years, hashes existed without field-level expiration as TTL worked only at the key level. Due to this limitation most of us modeled data in Redis in a flat structure

127.0.0.1:6379> keys *
1) "user:123:otp"
2) "user:123:refresh_token"
3) "user:123:session_token"
127.0.0.1:6379>

The above data-modelling used to work. But it also meant

• More keys in Redis.
• Higher memory overhead per key.
• More network round trips.
• More cluster slot scattering in Redis Cluster.

Introducing Hash Field Expiration

Let’s say we are using Redis as cache in our system, we need to store user’s otp, session_token and refresh_token but all keys need to have different TTL.

• The otp should expire in 60 seconds.
• The session_token should expire in 30 minutes.
• The refresh_token should live for 7 days.

In 2024, Redis finally introduced hash field expiration. Now you can attach TTL directly to an individual field inside a hash.

127.0.0.1:6379> HSETEX user:123 EX 60 FIELDS 1 otp 456789
(integer) 1
127.0.0.1:6379> HSETEX user:123 EX 1800 FIELDS 1 session_token abc123
(integer) 1
127.0.0.1:6379> HSETEX user:123 EX 604800 FIELDS 1 refresh_token xyz789
(integer) 1
127.0.0.1:6379> keys *
1) "user:123"
127.0.0.1:6379> HTTL user:123 FIELDS 3 otp session_token refresh_token
1) (integer) 19
2) (integer) 1768
3) (integer) 604779

Now only the otp field expires after 60 seconds. The rest of the user:123 hash remains untouched. This may look like a small addition, but it removes a modeling constraint that has existed since 2010.

Along with field-level TTL, Redis introduced companion commands that make this practical in real systems:

• HSETEX sets a field and assigns TTL in one atomic operation.
• HGETEX retrieves a field and optionally updates its expiration, which is ideal for sliding sessions.
• HGETDEL retrieves and deletes a field atomically, making it perfect for one-time tokens or idempotency patterns.

This may feels like convenience. But the deeper impact shows up in performance, memory usage and architecture, which I tried to test on my M4 Pro.

Performance Impact

Field-level expiration reduces unnecessary commands and round trips.

Previously, if you wanted to set a field and expire it, you needed two operations. Now you can do it atomically in one command. At high QPS, cutting even one network hop per request matters.

Under the hood, Redis also introduced a new internal structure called ebuckets to efficiently manage millions of field-level expirations. Instead of scanning randomly or maintaining a massive sorted structure, Redis groups expirations into time-based buckets and processes them incrementally. This keeps expiration predictable and prevents CPU spikes, even when large numbers of fields expire around the same time.

In practical terms, expiration remains fast and controlled even at scale.

Memory Efficiency

Every Redis key carries metadata overhead, dictionary entries, SDS structures, expiration tracking etc. If you have 1 million users and 3 expiring attributes per user, the traditional modeling approach creates 3 million keys.

With hash field expiration, you can store 1 million hash keys with fine-grained expiration inside them. At scale, that difference is huge. It directly impacts memory footprint and operational stability.

Benchmarking

I ran a simple benchmark on my local Redis instance using 100,000 users. Each user had

• otp
• session_token
• refresh_token

Persistence disabled for clean memory numbers

• Scenario A — Flat Key Structure : Total keys created: 300,000
• Scenario B — Hash + Field-Level TTL: Total keys created: 100,000

Result

Flat structure: ~29.38 MB  # ~293 bytes per user
Hash structure: ~18.85 MB  # ~188 bytes per user
Memory saved: ~10.5 MB (~35%)

At small scale, this may not look dramatic. But at 10 million users, that’s about 1 GB of memory saved. At 50 million users, that’s roughly 5 GB. And this is purely from reducing key-level overhead — not changing value sizes or business logic.

My Takeaway

Hash field expiration doesn’t just make modeling cleaner. It significantly reduces memory overhead by lowering key cardinality and shrinking top-level metadata structures. This is one of those small Redis changes that quietly improves system efficiency at scale.