Backend interview: How would you design hash-field TTLs with Redis HEXPIRE?

Prompt and context

The system wants multiple fields in one Redis hash, each with a different lifetime. Explain how to use HEXPIRE, handle renewal conditions, read expiry state, reclaim memory, support old versions, and recover. Do not stop at command syntax.

What the interviewer evaluates

• Understanding that Redis 7.4 extends expiration granularity from keys to hash fields.
• Correct use and explanation of NX, XX, GT, LT, and command return values.
• Consideration of expiration timing, read/write races, notifications, persistence, and memory budget.
• A plan for version detection, fallback, monitoring, and recovery.

Clarifying questions to ask

1. May fields expire independently, or must several fields update atomically?
2. Is TTL relative to a business event or a fixed deadline? May repeated writes extend it?
3. Should an expired field return missing, a default, or trigger recomputation? Are expiry events needed?
4. What Redis version, cluster mode, persistence, and client support are available?

30-second answer framework

I would confirm that independent lifetimes justify one hash, then define TTL, renewal conditions, and missing-value semantics for each field. HEXPIRE sets relative seconds per field and NX, XX, GT, and LT prevent accidental shortening or extension; return values belong in monitoring. Before launch I would test reads, rewrites, expiry notifications, recovery, and old-version fallback. Field expiration is not a promise of an exact deletion instant.

Step-by-step deep dive

1. Model each field lifecycle

Define the source, maximum freshness, renewal event, and post-expiry value for every field. Fields that require an atomic multi-field update can still share a hash, but TTL changes and business writes need a retryable protocol.

2. Choose renewal conditions

Use NX for a first expiry, XX only when an expiry already exists, GT only for a longer TTL, and LT only for a shorter one. Record each command result so missing fields, failed conditions, successful updates, and immediate deletion are distinguishable.

3. Handle expiration and notifications

Field expiration does not mean an application thread receives an event at an exact instant. Reads must accept a missing field, and writers must not restore an old snapshot. If expiration drives recomputation, combine keyspace notifications or a business queue with compensation for duplicate or lost events.

4. Plan compatibility, monitoring, and recovery

Detect Redis version and client capability at startup. If field TTL is unavailable, fall back to separate keys while documenting memory and atomicity changes. Monitor remaining TTL, condition failures, expiry events, hit rate, and memory; after RDB/AOF recovery, reconcile critical field deadlines and recomputation jobs.

Model answer

I would write down each field's lifecycle, renewal source, and expired behavior before deciding whether shared hash reads and atomic updates matter. I would set field TTLs with HEXPIRE, use NX for first writes and XX for existing TTLs, and consider GT or LT to prevent accidental extension or shortening while recording return values. Reads treat expired fields as missing and do not depend on an exact deletion notification; recomputation uses notifications plus an idempotent business queue. I would test version detection, recovery, TTL/hit-rate/memory monitoring, and a separate-key fallback.

Common mistakes

• Treating HEXPIRE as an alias for key-level EXPIRE.
• Misunderstanding NX, XX, GT, and LT so repeated writes change TTL accidentally.
• Assuming a field is deleted at an exact second and emits one guaranteed event.
• Ignoring old Redis versions, clients, or cluster compatibility.
• Omitting missing-field, recomputation, duplicate-notification, and recovery semantics.
• Monitoring hit rate but not TTL, condition failures, or memory reclamation.

Follow-up questions and responses

When should you still use separate keys?

Use separate keys when fields need independent atomic updates across services, clients lack field-TTL support, or key-level expiration better matches access patterns. Quantify extra key count, memory, and consistency costs.

Why is GT useful for recommendation features?

Recommendation features usually should extend freshness only when a newer event provides a longer deadline. GT rejects a shorter TTL so a late old event cannot expire fresh data early.

How do you handle a lost expiry notification?

Treat notifications as acceleration, not the sole source of truth. Cache misses, periodic remaining-TTL scans, business watermarks, and an idempotent recomputation queue should cover lost or duplicate events.