TTL, Expiration, And Snapshot Semantics

What's being tested

This tests time-aware in-memory state management: storing records whose visibility depends on currentTime, ttl, and snapshot/restore rules. Interviewers are probing whether you can design clean data structures, implement deterministic expiration, and preserve correctness across scans, quotas, backups, restores, and versioned mutations.

Patterns & templates

• Lazy expiration — check expireAt <= now inside get, scan, list, and backup; avoid eager cleanup unless required.

• Absolute expiry timestamps — store expireAt = timestamp + ttl, not remaining TTL; use None or INF for non-expiring records.

• Snapshot semantics — backup(now) should persist only live records, often as remaining TTL: remaining = expireAt - now.

• Restore semantics — rebuild expiry relative to restore time: newExpireAt = restoreTime + savedRemainingTtl; preserve non-expiring values unchanged.

• Nested maps — common shape is db[key][field] = {value, expireAt}; operations are usually O(1) point lookup and O(k log k) sorted scans.

• Deterministic scans — prefix scans require filtering live fields first, then lexicographic sort; do not rely on hash-map iteration order.

• Quota plus TTL accounting — storage usage must exclude expired files/tasks; call purgeExpired(user, now) before capacity checks or priority lists.

Common pitfalls

Pitfall: Treating TTL as duration forever instead of converting to an absolute deadline causes incorrect behavior after multiple reads, backups, or restores.

Pitfall: Backing up expired records because they still exist in the hash map violates snapshot semantics; logical liveness matters more than physical presence.

Pitfall: Sorting before filtering can leak expired fields into prefix scans or produce wrong ordering when deleted/reinserted records share names.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.