What they're testing
Whether you separate "avoid duplicate work" from "must never happen twice".
The short answer~30 seconds
If the lock only prevents two instances doing the same expensive work, SET key value NX PX 30000 is enough and very common. If running twice corrupts data, a distributed lock isn't sufficient — the holder can be paused by GC or partitioned away, the lock expires, another instance takes it, and then the first wakes up still believing it holds the lock. No timeout removes that scenario.
The long answer
The correct handling for the correctness case is a fencing token: each grant returns a monotonically increasing number, and the PROTECTED RESOURCE rejects any write carrying a token lower than the highest it has seen. So the late-waking instance can still write and will be refused. The crux is that the check lives at the resource, not at the client — and if the resource can't do it, you have no guarantee at all.
On Redlock, the multi-node Redis algorithm: it produced a public disagreement between Martin Kleppmann and Salvatore Sanfilippo, and the takeaway is that it relies on assumptions about clocks and bounded network delay — neither of which holds in an asynchronous system. For genuine correctness you want a consensus system (etcd, ZooKeeper, Consul), not a cache.
The most pragmatic answer, though, is usually avoiding the need. If the job can run twice without changing the outcome — that is, it's idempotent — you need no guarantee. If the work partitions by key and each key is owned by one consumer, you need none either. A great many distributed-lock requirements dissolve under that redesign, and proposing it is a clearer senior signal than naming etcd.
What they'll ask next
?What about cron running on several instances?
Don't have every instance run its own cron. Use an external scheduler (a Kubernetes CronJob, or a scheduled queue) that creates exactly one job which any free instance picks up. It converts a mutual-exclusion problem into a work-distribution one, which is much easier.
These lose points
- Using
SETNXthenEXPIREas two commands. Dying in between leaves the lock forever. It must be oneSET … NX PX. - Deleting the lock without checking ownership. You can delete someone else's after yours expired — it needs a Lua script that compares the value before deleting.