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 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.

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.

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 the section

Tech stacks

Skill areas

Suggest an improvement