1. Distributed locking

Picture a concert-ticketing platform with six identical worker instances. Each can rebuild venue 42's seat map, a single file in shared object storage. If two workers run that job at the same moment, each reads the old file, applies its own sales, and writes the result back. One worker's sales vanish, and a sold seat shows as available. You need to let only one worker touch venue 42 at a time, though the workers share no memory. That grant is a distributed lock: a record in a shared lock service that lets one process among many act on a resource at a time.

The hard part is not taking the lock. It is what happens when the holder crashes, freezes, or loses its network while it holds it. This tutorial covers locks that expire (leases), a token the storage checks so a stale holder cannot write (fencing), and where the lock should live, including when you need none. It also explains why a lock backed by a consensus store still cannot guarantee a single writer on its own.

Distributed locking is rarely a whole interview round. It usually shows up as a three-to-five-minute follow-up after your high-level design: "what if two instances do this at once?" and then "what if that instance dies?".

At mid-level, knowing that locks must expire and that a version check on the row often replaces the lock is enough. At senior level, interviewers expect you to walk the paused-holder failure unprompted and put the check inside the resource.