Concept questionHard~9 minCaching & Redis Essentials / 11 of 15

Interview question

When would you use a Redis distributed lock, and what can go wrong?

Use Redis locks only with clear lease boundaries

Explains the risks of Redis-based distributed locks and when database constraints, queues, or idempotency are safer.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would use a Redis lock only for a short, bounded coordination problem where duplicate work is undesirable but the system can tolerate lease expiry behavior. The lock needs an expiration so it does not stay forever if the holder crashes. The worker also needs to know that the lock can expire before work finishes, so the protected operation should still be idempotent or guarded by a stronger source-of-truth rule.

Full answer below

Practice focus

Distributed coordination, lock expiry, leases, ownership tokens, idempotency, database constraints, and failure modes.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A Redis lock is a time-bounded lease, not a durable mutex. Expiry, pauses, partitions, failover, and ownership races mean correctness still needs an idempotent operation, database constraint, or another durable boundary.
I would use a Redis lock only for a short, bounded coordination problem where duplicate work is undesirable but the system can tolerate lease expiry behavior. The lock needs an expiration so it does not stay forever if the holder crashes. The worker also needs to know that the lock can expire before work finishes, so the protected operation should still be idempotent or guarded by a stronger source-of-truth rule.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For many correctness problems, I would prefer database uniqueness, optimistic concurrency, transactions, queues, or idempotency keys over a distributed lock. A Redis lock can help reduce duplicate refreshes or schedule one background task, but it should not be the only protection for money movement, inventory reservation, or authorization. If I use one, I would include an ownership token and release only the lock I acquired.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I use a unique ownership token, compare-and-delete release, conservative expiry, and renewal only while the holder still owns healthy work. I assume the lease can expire before the operation finishes and use fencing tokens or durable version checks where a stale holder could overwrite newer work. Contention, acquisition latency, expired holders, renewal failures, and duplicate execution are observable. Money, inventory, and authorization rely on database or domain invariants rather than on the lease alone.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using Redis locks as the only correctness mechanism for critical data.
Creating locks without expiry.
Releasing a lock without verifying ownership.
Running long work under a short lease without idempotency.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain lease expiry.
No ownership token.
No durable backup rule like a unique constraint.
Treats Redis lock as identical to an in-process lock.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a database constraint better than a Redis lock?
What happens if the worker pauses longer than the lock TTL?
How would you safely release a lock?

Continue the section

Next in Caching & Redis Essentials: Hot Key

Step 12 of 15

Diagnose a hot key causing uneven Redis load

Opening drill

Concept questionHard~9 minCaching & Redis Essentials / 11 of 15

Interview question

When would you use a Redis distributed lock, and what can go wrong?

Use Redis locks only with clear lease boundaries

Explains the risks of Redis-based distributed locks and when database constraints, queues, or idempotency are safer.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Distributed coordination, lock expiry, leases, ownership tokens, idempotency, database constraints, and failure modes.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A Redis lock is a time-bounded lease, not a durable mutex. Expiry, pauses, partitions, failover, and ownership races mean correctness still needs an idempotent operation, database constraint, or another durable boundary.
I would use a Redis lock only for a short, bounded coordination problem where duplicate work is undesirable but the system can tolerate lease expiry behavior. The lock needs an expiration so it does not stay forever if the holder crashes. The worker also needs to know that the lock can expire before work finishes, so the protected operation should still be idempotent or guarded by a stronger source-of-truth rule.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For many correctness problems, I would prefer database uniqueness, optimistic concurrency, transactions, queues, or idempotency keys over a distributed lock. A Redis lock can help reduce duplicate refreshes or schedule one background task, but it should not be the only protection for money movement, inventory reservation, or authorization. If I use one, I would include an ownership token and release only the lock I acquired.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I use a unique ownership token, compare-and-delete release, conservative expiry, and renewal only while the holder still owns healthy work. I assume the lease can expire before the operation finishes and use fencing tokens or durable version checks where a stale holder could overwrite newer work. Contention, acquisition latency, expired holders, renewal failures, and duplicate execution are observable. Money, inventory, and authorization rely on database or domain invariants rather than on the lease alone.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using Redis locks as the only correctness mechanism for critical data.
Creating locks without expiry.
Releasing a lock without verifying ownership.
Running long work under a short lease without idempotency.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain lease expiry.
No ownership token.
No durable backup rule like a unique constraint.
Treats Redis lock as identical to an in-process lock.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a database constraint better than a Redis lock?
What happens if the worker pauses longer than the lock TTL?
How would you safely release a lock?

Continue the section

Next in Caching & Redis Essentials: Hot Key

Step 12 of 15

Diagnose a hot key causing uneven Redis load

When would you use a Redis distributed lock, and what can go wrong?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

When would you use a Redis distributed lock, and what can go wrong?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section