Memcached Expiration: Transitioning from Relative TTL to Absolute Unix Timestamps

Question

Memcached manages item expiration using a 32-bit unsigned integer. The system distinguishes between a relative offset and an absolute timestamp based on a specific threshold: values under 2,592,000 seconds (30 days) are treated as relative TTLs, while values exceeding this limit are interpreted as Unix epoch timestamps.

When migrating data structures or adjusting cache durations, there is uncertainty regarding how the slab allocator and lazy expiration process handle items that cross this 30-day boundary. Because Memcached treats stored values as opaque blobs, the internal expiration logic relies entirely on the integer passed during the set or add command.

If a client application provides a timestamp that is slightly off due to clock drift across a distributed cluster, the behavior of the item's lifecycle becomes unpredictable.

Does the lazy expiration mechanism trigger differently for absolute timestamps compared to relative offsets?
  How does the system resolve conflicts when distributed clients provide inconsistent Unix timestamps for the same key?

Tasadduq Burney · Answer

Answer
Lazy expiration works identically for relative TTLs and absolute Unix timestamps because Memcached converts the supplied 32‑bit value to an absolute timestamp at store time. When multiple clients set the same key with differing timestamps, the most recent set (or add) wins; the item’s expiration reflects the timestamp from that last write.
Likely Explanation
Memcached does not keep the original expiration format; it stores a single absolute Unix epoch time. The lazy expiration mechanism (checked on get or during slab allocation) simply compares that stored time with the current server time, so the path taken during storage does not affect the check.
Confirmed Facts

Values < 2,592,000 seconds (30 days) are treated as relative offsets: absolute = now + offset.
  Values ≥ 2,592,000 seconds are used directly as absolute timestamps.
  The stored absolute timestamp is what lazy expiration compares against current_time.
  Concurrent writes to the same key overwrite previous values; expiration follows the timestamp from the latest write.

Verification Steps

Start a local memcached instance: memcached -p 11211 -d
  Set a key with a relative TTL of 1 second:
    echo -e "set key 0 0 1
value
" | nc localhost 11211
    Immediately get to confirm it exists, wait >1 s, then get again to see a miss.
  Set the same key with an absolute timestamp equal to current_time + 1 second (obtain current_time with date +%s):
    NOW=$(date +%s); ABS=$((NOW+1)); echo -e "set key 0 $ABS 1
value
" | nc localhost 11211
    Verify identical expiration behavior as in step 2.
  Inspect the internal storage with stats items; the age or expire field will show the same absolute timestamp for both approaches.
  Simulate client clock drift by setting the client’s system clock ahead or behind, issue a set with an absolute timestamp, and observe that expiration follows the server’s time, not the client’s offset.

Missing Diagnostic Detail
Are all memcached servers in your cluster synchronized via NTP (or equivalent)? Significant drift can cause items to appear expired prematurely or persist longer than intended, which would affect the reliability of the above behavior.

Memcached Expiration: Transitioning from Relative TTL to Absolute Unix Timestamps

1 answer

Answer

Likely Explanation

Confirmed Facts

Verification Steps

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments