Distributed Lock Service System Design Interview Walkthrough

A distributed lock service lets processes on different machines agree that only one of them holds a named lock at a time. In the distributed lock service system design interview, the interviewer is scoring three things: how you clarify requirements, how coherent your architecture is, and whether you can defend your trade-offs out loud. Most candidates jump to Redis or ZooKeeper and skip the reasoning. This walkthrough keeps you explaining why at every step, with a script you can say at each stage across 35 to 40 minutes.

What the interviewer is actually listening for

A lock sounds simple until you ask what happens when the holder pauses, the network splits, or the lock service itself fails over. The interviewer usually cares less about which product you name and more about whether you have thought past the happy path.

Three signals separate a strong answer from a memorised one:

• Requirement clarification. You turn a vague prompt into a short list of what the lock must guarantee and what it can give up.
• A coherent architecture. Each box has a reason to exist, and you can say the acquire and release flow aloud as you draw it.
• Defended trade-offs. You name the cost of each choice before the interviewer has to pull it out of you.

The single idea that lifts this answer is the fencing token. If you understand why a lease alone is not enough, you can handle most follow-ups.

The time-boxed checklist to keep in front of you

Keep this list where you can see it while you rehearse. It maps the whole distributed lock service system design interview onto the sections below.

1. Requirements, 5 minutes. Functional checklist plus the non-functional side.
2. Architecture, 10 minutes. Five boxes and the spoken acquire flow.
3. Lease and fencing tokens, 10 minutes. The stale-write example, said out loud.
4. Trade-offs, 10 minutes. Three decisions, each with a named cost.
5. Failure cases, 5 minutes. Four probes, one or two sentences each.
6. Close, 2 minutes. Scale, monitoring and what you would do next.

If you fall behind, protect the fencing-token section. It is the part that shows you understand the problem rather than reciting a product.

Step 1: Clarify requirements before you draw anything (5 minutes)

Spend the first five minutes turning the prompt into requirements. This is where many candidates lose the thread, because they start sketching boxes before they know what the lock must do.

Run through a functional checklist and confirm each item with the interviewer:

1. Acquire and release. Can a client ask for a named lock and give it back explicitly?
2. Lease expiry. Does a lock expire on its own if the holder goes quiet?
3. Ownership. Must only the owner release the lock, or can anyone?
4. Reentrancy. Can the same client re-acquire a lock it already holds?
5. Wait and queue behaviour. Do waiting clients queue in order, or retry best-effort?
6. Observability. Do we need to see who holds what, and for how long?

Then pin down the non-functional side: correctness matters more than availability for a lock, so the service should prefer refusing an acquire over risking two holders. Ask about the latency budget for an acquire, the expected throughput, and what should happen during a network partition. If you want the general habit of turning vague goals into numbers, our article on non-functional requirements in a system design interview is a good rehearsal.

Here is a five-minute opening you can adapt:

"Before I design, I want to confirm the scope. My understanding is we need mutual exclusion on named locks across machines, with a lease so a crashed holder does not block everyone forever. I'd like to check three things: do we need fairness, meaning waiting clients acquire in order, and do we need reentrancy for the same client? And for the non-functional side, I'll assume correctness beats availability, so we never allow two holders, and an acquire latency of a few milliseconds is fine. Does that match what you have in mind?"

Saying this out loud signals that you know where the hard parts are. It also gives the interviewer a chance to narrow the scope, which makes the rest of your answer sharper.

Step 2: Sketch the architecture in five boxes (10 minutes)

The architecture has five parts. Name them, draw them, and narrate the flow as you go.

• Client library. Wraps acquire, renew and release calls, and holds the current fencing token.
• Lock service API. The front door that validates requests and routes them to the store.
• Consistent store. A replicated key-value store or coordination service that holds the lock records and issues tokens.
• Lease and expiry mechanism. Tracks time-to-live and reclaims expired locks.
• Monitoring path. Emits metrics and logs for holders, waits and rejections.

The store is the part that must be right. It needs linearizable writes or a consensus protocol for the lock record, because two clients must never both see themselves as the winner. If you are unsure how to phrase that, our guide on consistency models in a system design interview gives you the vocabulary.

Then say the flow aloud as you draw arrows:

1. Client asks the API for lock orders:42 with a lease of ten seconds.
2. The API writes the lock record through the consistent store, which grants the lock and returns a fencing token.
3. The client receives the token and starts its critical work.
4. The client renews the lease before it expires, while it still needs the lock.
5. On release, the client calls the API, which clears the record.

Narrating the flow catches gaps early. If you cannot say a step aloud, the diagram is hiding a decision you have not made.

Step 3: Choose a lease-based lock with fencing tokens (10 minutes)

A lease gives the lock a time-to-live. The holder must renew before expiry, and if it does not, the service reclaims the lock. That solves the crashed-holder problem, but it creates a subtler one: a holder can pause, lose its lease without knowing, and then wake up believing it still owns the lock.

Fencing tokens close that gap. Each time the service grants a lock, it issues a monotonically increasing number. The protected resource, such as a storage system or a downstream service, records the highest token it has seen and rejects anything lower.

Here is the worked example to say out loud:

"Client A acquires the lock and gets token 41. It pauses, maybe a long garbage collection or a stalled network call. The lease expires. Client B acquires the same lock and gets token 42. Client A wakes up and tries to write to the protected resource. The resource has already seen 42, so it rejects A's write because 41 is stale. The lock service did its job, and the resource stayed safe."

This is the section that separates a strong answer from a memorised one. If you can explain the stale write being rejected, you have shown you understand why leases alone are not enough.

Step 4: Defend the trade-offs out loud (10 minutes)

Interviewers probe trade-offs because they want to hear you choose, not list. Use a short template for each one: "I would choose X here because Y, accepting Z as the cost."

A spoken version for the first row:

"I would choose to refuse an acquire during uncertainty because a lock that allows two holders is worse than a lock that briefly says no. I accept that some clients will see errors during a partition, and I would surface that clearly rather than pretend the lock is available."

The template works because it forces you to name the cost. Naming the cost usually ends that line of probing.

Step 5: Walk through the failure cases (5 minutes)

Expect follow-ups on failure. Have four answers ready.

• Holder crashes mid-lease. Expiry reclaims the lock, and the fencing token protects the resource from a late write.
• Network partition between holder and lock service. The holder may believe it still owns the lock. The resource-side token check is the backstop, which is why the token must travel with every write.
• Lock service leader failover. In-flight acquires may fail and need a retry. Make retries idempotent so a client does not end up with two lock records.
• Clock skew. Measure lease expiry on the service side, not the client side, so a skewed client clock cannot extend or shorten a lease.

Say each one in a sentence or two. The goal is to show you have a defence for each, not to write a novel.

Step 6: Close with scale, monitoring and what you would do next (2 minutes)

Finish by showing you know what changes under load. At higher throughput, you would shard lock namespaces so different locks do not compete for the same record, batch renewals to cut round trips, and cache read-only lock status where a stale answer is acceptable.

Name what you would monitor: acquire latency, lease expiry rate, fencing-token rejections, and lock contention. Those four tell you whether the service is healthy or quietly losing leases.

Then hand the interview back with a closing script:

"If I had more time, I would dig into fairness and cross-region behaviour, and I would want to see how the fencing-token check performs on the resource side under load."

Ending with what you would do next shows judgement about scope, which is part of what the distributed lock service system design interview is testing.

The three mistakes that sink this interview

Most weak answers fail in predictable ways. Here they are, with a one-line fix for each.

• Jumping to a product before stating requirements. Fix: spend the first five minutes on requirements, then name a product only as an example.
• Forgetting fencing tokens. Fix: make the stale-write example part of your answer, not an afterthought.
• Treating the lock service as always available. Fix: say explicitly that you prefer refusing an acquire over risking two holders.

Each fix takes one sentence, and each one signals that you have thought about the failure modes.

How to practise this walkthrough before the interview

Run a 30-minute solo drill with a timer and a voice recorder:

1. Five minutes: requirements checklist and the opening script.
2. Ten minutes: five-box architecture and the spoken acquire flow.
3. Ten minutes: trade-offs using the template, including the fencing-token example.
4. Five minutes: the four failure cases.

Play the recording back and check for the three mistakes above. If you hear yourself naming a product before requirements, redo the first five minutes. If the fencing example is missing, say it twice more until it is automatic.

Our guide on API design in a system design interview is a useful companion for describing the lock service contract clearly.

Before you walk in

This question rewards reasoning, not recall. If you can clarify requirements, draw five boxes, explain why a lease needs a fencing token, and name the cost of each trade-off, you have the whole answer. Practise the stale-write example until you can say it in your sleep, then record one full 35-minute run and listen for the three mistakes. That single rehearsal is the best preparation you can do.

Frequently asked questions

Should I use Redis or ZooKeeper in the distributed lock service system design interview, or stay abstract?

Name a product only as an example after you have stated requirements. Interviewers usually care whether you can explain linearizable writes, leases and fencing tokens, not whether you memorised a vendor's API. Start abstract, then say something like "a replicated key-value store or coordination service could back this" and let the interviewer steer if they want a specific one.

How long should the requirements section take before I start drawing?

Aim for about five minutes out of a 35 to 40 minute walkthrough. That is long enough to confirm acquire, release, lease expiry, ownership, reentrancy and fairness, plus the non-functional side, without eating into the architecture time. If the interviewer narrows scope quickly, you can move on sooner.

What if the interviewer asks me to make the lock service highly available?

Say what you would give up. A lock service can be highly available, but the safer default is to refuse an acquire during uncertainty rather than risk two holders. Offer to relax that only if the interviewer confirms the protected resource can tolerate occasional double ownership, and explain that fencing tokens are the backstop either way.

Do I need to discuss reentrancy and fairness, or can I skip them?

Mention them once, then follow the interviewer's lead. If they say both are out of scope, drop them without argument and spend the saved time on fencing tokens and failure cases. If they leave it open, keep the default of no reentrancy and best-effort acquisition, and say that choice out loud so it is on the record.

Rehearse the full walkthrough out loud and review where your reasoning slipped.