Distributed Locking with Redisson in Spring Boot

Distributed locking with Redis is a common interview topic because it looks simple but has real failure modes. The naive implementation — SET key NX EX 30 — works in single-node Redis but not across a cluster under failure scenarios.

Why the naive `SETNX` approach is fragile

• SET key NX EX 30 creates a key only if it doesn't exist, with a 30-second TTL — which means the first caller acquires the lock and others fail fast; this works on a single Redis instance
• The problem: if the Redis primary fails after the key is set but before the replica replicates it, a new primary is elected without the lock key, and a second caller acquires the lock — two holders of the "exclusive" lock simultaneously

Redlock — the multi-node algorithm

• Redlock acquires the lock on N independent Redis instances (not a cluster) — for a lock to be held, it must be acquired on a majority (N/2 + 1) of instances; a single instance failure doesn't break the lock because the majority still holds it
• Redisson implements Redlock in Java with RLock — lock.tryLock(waitTime, leaseTime, TimeUnit.SECONDS) handles the multi-instance coordination automatically

Lease time and watchdog

• Every distributed lock needs a TTL to prevent a crashed holder from holding the lock forever — Redisson's RLock defaults to a 30-second lease and a watchdog thread that renews the TTL every 10 seconds while the holder is alive
• The watchdog stops renewing if the application process dies — which means the lock eventually expires naturally, and other holders can acquire it

When distributed locking is overkill

• For most application-level mutual exclusion, optimistic locking with a database version column is simpler and doesn't require Redis — use @Version in JPA; a conflicting update throws OptimisticLockException and the caller retries