3 / 5 Invalidation & Cache Consistency

The Token Went Stale

A memcached tier runs with leases. A lease is a 64 bit token bound to the key, handed to the client that took the miss, and presented back on the SET.

time client A, read path client B, write path value in memcached
t0 GET profile:551 misses, receives lease token 0x7f2a absent
t1 reads the row from the database: name = "Ada" absent
t2 commits UPDATE ... name = "Grace" absent
t3 DELETE profile:551 absent
t4 SET profile:551 = "Ada" with token 0x7f2a ?

What does memcached hold after t4, and why?

A

"Grace", because memcached re-reads the row when it detects a conflicting set

B

Nothing, because the lease expired on its own before t4

C

Nothing: the delete at t3 invalidated token 0x7f2a, so the set is rejected and the next reader misses and loads "Grace"

D

"Ada", and it stays until the TTL expires, because a set always wins over an earlier delete

E

"Ada", stored but flagged stale, so readers get it with a warning and refresh in the background