Architecture scenarioHard~12 min

Interview question

You must prevent two operations for the same customer or order from running together, while allowing different keys to proceed concurrently. How would you design it?

Coordinate concurrent operations with per-key locking

Serializes work for the same resource while preserving concurrency across independent keys and managing keyed-lock lifetime safely.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would map each stable resource key to a gate such as a SemaphoreSlim(1, 1). An operation waits asynchronously for that key, performs only the state transition that must be serialized, and releases the gate in finally. Operations for different keys use different gates and can continue concurrently. The key must represent the real invariant, so two spellings or aliases for the same customer cannot produce separate locks.

Full answer below

Practice focus

Keyed semaphores, resource ownership, lifecycle cleanup, cancellation, fairness, bounded memory, multi-instance limits, and partitioned alternatives.

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
One global lock protects correctness but destroys unrelated concurrency. Keyed coordination narrows the boundary, yet it introduces lifecycle and distributed-scope problems that need an explicit design.
I would map each stable resource key to a gate such as a SemaphoreSlim(1, 1). An operation waits asynchronously for that key, performs only the state transition that must be serialized, and releases the gate in finally. Operations for different keys use different gates and can continue concurrently. The key must represent the real invariant, so two spellings or aliases for the same customer cannot produce separate locks.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A plain ConcurrentDictionary<TKey, SemaphoreSlim> is only the beginning because entries can grow forever and unsafe removal can create two live gates for one key. I would use a tested keyed-lock abstraction with reference counting or a bounded partitioned design. Cancellation should apply while waiting, and release should happen only after successful acquisition. I would keep slow external I/O outside the keyed critical section when possible, or move the full workflow to a queue partition if order for that key is the actual requirement.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would decide whether the invariant is local or global. An in-memory keyed gate works inside one process, but two application instances can still run the same key concurrently. For global correctness I may need a database uniqueness or concurrency constraint, a transaction, a broker partition keyed by resource, or a carefully operated distributed lock with fencing. I would monitor active keys, wait duration, queue depth per hot key, timeout and cancellation rates, and gate cleanup. I would load-test a skewed key distribution rather than only evenly distributed traffic, because one popular key is often the real bottleneck. Hot-key behavior needs a product policy because one customer with a backlog can suffer starvation even while overall throughput looks healthy.

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 raw input as a key without canonicalizing resource identity.
Removing a dictionary entry while another waiter can still acquire the old gate.
Forgetting to release after an exception or releasing after a canceled wait that never acquired.
Assuming an in-memory gate serializes work across a scaled-out service.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The keyed-lock dictionary has no bounded lifetime or cleanup design.
The protected section includes unrelated slow work by default.
No durable constraint backs a business-critical invariant.
Hot keys and wait time are not observable.

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.

Why is safe keyed-lock cleanup difficult?
When would broker partitioning be a better ownership model?
What durable check would protect the invariant across instances?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

SemaphoreSlim

Architecture scenarioHard~12 min

Interview question

You must prevent two operations for the same customer or order from running together, while allowing different keys to proceed concurrently. How would you design it?

Coordinate concurrent operations with per-key locking

Serializes work for the same resource while preserving concurrency across independent keys and managing keyed-lock lifetime safely.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Keyed semaphores, resource ownership, lifecycle cleanup, cancellation, fairness, bounded memory, multi-instance limits, and partitioned alternatives.

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
One global lock protects correctness but destroys unrelated concurrency. Keyed coordination narrows the boundary, yet it introduces lifecycle and distributed-scope problems that need an explicit design.
I would map each stable resource key to a gate such as a SemaphoreSlim(1, 1). An operation waits asynchronously for that key, performs only the state transition that must be serialized, and releases the gate in finally. Operations for different keys use different gates and can continue concurrently. The key must represent the real invariant, so two spellings or aliases for the same customer cannot produce separate locks.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A plain ConcurrentDictionary<TKey, SemaphoreSlim> is only the beginning because entries can grow forever and unsafe removal can create two live gates for one key. I would use a tested keyed-lock abstraction with reference counting or a bounded partitioned design. Cancellation should apply while waiting, and release should happen only after successful acquisition. I would keep slow external I/O outside the keyed critical section when possible, or move the full workflow to a queue partition if order for that key is the actual requirement.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would decide whether the invariant is local or global. An in-memory keyed gate works inside one process, but two application instances can still run the same key concurrently. For global correctness I may need a database uniqueness or concurrency constraint, a transaction, a broker partition keyed by resource, or a carefully operated distributed lock with fencing. I would monitor active keys, wait duration, queue depth per hot key, timeout and cancellation rates, and gate cleanup. I would load-test a skewed key distribution rather than only evenly distributed traffic, because one popular key is often the real bottleneck. Hot-key behavior needs a product policy because one customer with a backlog can suffer starvation even while overall throughput looks healthy.

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 raw input as a key without canonicalizing resource identity.
Removing a dictionary entry while another waiter can still acquire the old gate.
Forgetting to release after an exception or releasing after a canceled wait that never acquired.
Assuming an in-memory gate serializes work across a scaled-out service.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The keyed-lock dictionary has no bounded lifetime or cleanup design.
The protected section includes unrelated slow work by default.
No durable constraint backs a business-critical invariant.
Hot keys and wait time are not observable.

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.

Why is safe keyed-lock cleanup difficult?
When would broker partitioning be a better ownership model?
What durable check would protect the invariant across instances?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

SemaphoreSlim

You must prevent two operations for the same customer or order from running together, while allowing different keys to proceed concurrently. How would you design it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

You must prevent two operations for the same customer or order from running together, while allowing different keys to proceed concurrently. How would you design it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper