Imagine two kids at a dinner table. One kid is holding the fork and wants the knife. The other kid is holding the knife and wants the fork. Neither one will let go of what they already have. So both kids just sit there, staring at each other, waiting forever. Nobody eats. That, in a nutshell, is a deadlock — it is not a bug that someone wrote by mistake, it is a natural traffic jam that can happen any time two or more things are sharing limited resources and refuse to give way.

In a database, a deadlock happens when two or more transactions (think of a transaction as “a piece of work someone asked the database to do”) each hold onto a piece of data that the other one needs, and each one is waiting for the other to release it first. Since nobody backs down, nobody moves forward. The database has to step in, like a traffic officer, and force one of them to back up.

1.1 Where did this idea come from?

The term “deadlock” did not start in databases. It came from the early days of operating systems in the 1960s and 1970s, when computers first started running multiple programs (processes) at the same time and sharing devices like printers, tape drives, and memory. Computer scientists like Edsger Dijkstra studied this problem while working on early multiprogramming systems. Dijkstra’s famous “Dining Philosophers Problem” (1965) is the classic textbook illustration of deadlock: five philosophers sit around a table, each needs two forks to eat, but there are only five forks between them. If every philosopher picks up the fork on their left at the same time, everyone is holding one fork and waiting for the other — and nobody can ever eat.

As databases grew more sophisticated in the 1970s and 1980s — especially with the rise of relational databases like IBM System R and later Oracle, DB2, and SQL Server — the same underlying problem showed up again, but this time with database rows, tables, and locks instead of forks and philosophers. Database researchers borrowed the concept directly and built specific tools to detect and resolve it, because unlike an operating system managing a handful of devices, a busy production database might have thousands of transactions running per second, all touching overlapping rows.

1.2 A quick history-of-deadlocks timeline

1.3 Why this topic matters today

Modern applications — e-commerce checkouts, banking transfers, ride-sharing bookings, ticket sales — all rely on databases to safely handle many people trying to read and write the same data at the same time. Every time two customers try to book the last seat on a flight, or two people try to update the same shopping cart, there’s a chance of lock conflicts, and occasionally, a full deadlock. Understanding deadlocks is not an academic exercise; it’s a day-one skill for any backend engineer, and it’s one of the most commonly asked topics in system design and backend interviews.

To understand why deadlocks exist, we first need to understand why databases use locks in the first place.

2.1 Why do databases need locks at all?

Imagine a bank account with $100 in it. Two requests arrive at almost the exact same moment: one wants to withdraw $80, and another wants to withdraw $50. If the database let both requests read the balance ($100), do their math, and write back the result without any coordination, here is what could go wrong:

• Request 1 reads balance = $100
• Request 2 reads balance = $100 (before Request 1 finishes)
• Request 1 calculates $100 − $80 = $20 and writes $20
• Request 2 calculates $100 − $50 = $50 and writes $50

The final balance is $50 — but in reality, $130 was withdrawn from an account that only had $100. The bank just lost $80 it didn’t have. This is called a lost update, and it’s exactly the kind of chaos that locks are designed to prevent.

To stop this, the database uses locks: before a transaction is allowed to change a row, it must first “claim” that row, the same way you might grab a whiteboard marker before writing on a shared whiteboard — if someone else already has the marker, you wait until they put it down.

2.2 So why do deadlocks happen if locks fix the lost-update problem?

Locks solve the “two people editing at once” problem, but they introduce a new problem: waiting. And whenever you have multiple people waiting on multiple resources, in more than one order, you get the risk of a circular wait — a deadlock.

Here’s the key motivation for learning this topic: deadlocks are the unavoidable side effect of correctness. A database that never locked anything would never deadlock — but it also could not guarantee your bank balance is accurate. So instead of avoiding locks altogether, database engineers accept that deadlocks will occasionally happen, and build systems to detect them quickly and recover gracefully, usually within milliseconds.

2.3 A concrete beginner example

Let’s say you have a simple accounts table, and two transactions want to transfer money between two rows: Row A (Alice’s account) and Row B (Bob’s account).

T1 is waiting for T2, and T2 is waiting for T1. Neither can proceed. This is a deadlock, and without intervention, both transactions would sit frozen indefinitely, potentially blocking other users too.

Before we go deeper, let’s build a solid vocabulary. Every new word below is explained with what it is, why it exists, and a simple example.

3.1 Transaction

What it is: A transaction is a group of one or more database operations (reads and writes) that are treated as a single, indivisible unit. Either all of them succeed, or none of them do.

Why it exists: Real-world actions often need multiple steps. A bank transfer needs to subtract money from one account AND add it to another. If only one step happened (say, the computer crashed halfway), money would vanish or be duplicated. Transactions guarantee “all or nothing.”

Simple analogy: Think of a transaction like mailing a package with tracking. Either the package fully arrives, or it’s fully returned to you — it never “half-arrives” with only some contents.

Practical example:

BEGIN TRANSACTION;
  UPDATE accounts SET balance = balance - 80 WHERE id = 'Alice';
  UPDATE accounts SET balance = balance + 80 WHERE id = 'Bob';
COMMIT;

3.2 Lock

What it is: A lock is a flag the database attaches to a piece of data (a row, a page, or a table) to say “someone is using this right now, please wait your turn.”

Why it exists: Without locks, two transactions could read and write the same data at the same time and corrupt it (like the lost-update example earlier).

Simple analogy: A lock is like the “occupied” sign on an airplane bathroom door. If it’s occupied, you wait outside until the light changes to “vacant.”

Types of locks you’ll encounter:

3.3 Wait-for graph

What it is: A diagram (used internally by the database) that shows which transaction is waiting for which other transaction. Each transaction is a “node,” and an arrow points from the waiting transaction to the one holding the lock it wants.

Why it exists: It gives the database a simple way to check for deadlocks: if the arrows ever form a closed loop (a cycle), that’s a deadlock.

Simple analogy: Picture a game of “who owes who a favor.” If Alice owes Bob a favor, Bob owes Carol a favor, and Carol owes Alice a favor, that’s a closed loop — nobody can be the first to “cash in” their favor because everyone is waiting on someone else.

3.4 Isolation level

What it is: A setting that controls how strictly the database keeps transactions separated from each other’s in-progress changes. Common levels: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE.

Why it exists: Stricter isolation means fewer surprises (like reading data that later gets rolled back) but requires more locking, which increases the chance of deadlocks. It’s a trade-off dial between safety and concurrency.

Simple analogy: It’s like the difference between a shared Google Doc where everyone sees live edits (loose isolation) versus a Word document that must be checked out from a shared drive one person at a time (strict isolation).

3.5 Victim (in deadlock resolution)

What it is: When a database detects a deadlock, it picks one of the involved transactions to forcibly cancel (roll back) so the others can continue. That chosen transaction is called the “victim.”

Why it exists: Since a deadlock cannot resolve on its own, someone has to “lose” so the rest of the system can keep moving. The database tries to pick the least costly transaction to cancel (e.g., the one that has done the least work).

Simple analogy: It’s like a game of musical chairs where the referee has to pick one player to sit out so the game can continue for everyone else.

3.6 Timeout

What it is: A maximum amount of time a transaction is allowed to wait for a lock before the database gives up and cancels it.

Why it exists: Some databases (or configurations) don’t build a full wait-for graph; instead, they use a simpler safety net — if you’ve been waiting “too long,” you’re probably stuck, so just cancel and try again.

Simple analogy: If you call a customer support line and get put on hold with music for over 30 minutes, most people just hang up and call back later instead of waiting forever.

To catch and resolve deadlocks, a database server has a few internal components working together. You don’t need to build these yourself — every major database (MySQL/InnoDB, PostgreSQL, Oracle, SQL Server) has them built in — but understanding what they do helps you reason about production behaviour.

4.1 How this differs across databases

Let’s go step-by-step through exactly how a database identifies and breaks a deadlock internally.

5.1 Every lock request is recorded

When a transaction wants to read or write a row, it asks the Lock Manager for a lock on that row. The Lock Manager keeps a table (like a spreadsheet) of: which transaction holds which lock on which resource, and which transactions are waiting for which locks.

5.2 Waiting transactions are queued

If a lock is already held by someone else in a conflicting mode (e.g., you want an exclusive lock but someone else has a shared or exclusive lock), your transaction is placed into a wait queue for that specific resource, and your thread effectively “sleeps” until it’s notified.

5.3 The wait-for graph is built

The database builds a graph where each node is a transaction, and each directed edge (arrow) means “Transaction X is waiting for a lock held by Transaction Y.” This graph is rebuilt (or incrementally updated) whenever a new wait relationship appears.

5.4 Cycle detection runs

The deadlock detector runs a graph traversal algorithm (commonly Depth-First Search) starting from each waiting transaction, following the “waits for” arrows. If it ever revisits a node it has already seen in the current path, it has found a cycle — a deadlock.

5.5 A victim is chosen

Once a cycle is confirmed, the database must pick one transaction in that cycle to sacrifice. Common heuristics include:

• Least work done: Roll back whichever transaction has made the fewest changes so far (cheaper to undo).
• Youngest transaction: Roll back whichever transaction started most recently (the older one gets priority since it’s “been waiting longer” for its overall work).
• Fewest locks held: Roll back whichever transaction holds fewer resources, freeing up more for others faster.

5.6 Rollback and error signal

The chosen victim’s transaction is automatically rolled back (all its changes undone), all its locks are released, and the database returns a specific error to the client application — for example, MySQL returns error 1213 (ER_LOCK_DEADLOCK), and PostgreSQL returns SQLSTATE 40P01.

5.7 The surviving transaction proceeds

With the victim’s locks released, the other transaction(s) in the former cycle can now acquire the lock they were waiting for and continue normally.

Let’s trace the full lifecycle of a deadlock from beginning to end, using our earlier Alice/Bob bank transfer example, with exact timing.

Now let’s go a level deeper into the actual algorithms databases use to catch deadlocks. This is a popular interview topic, so we’ll be precise.

7.1 Wait-for graph + cycle detection (Depth-First Search)

What it is: As described earlier, the database models transactions as nodes and “waits for” relationships as directed edges, then runs a graph traversal to check for cycles.

Why it’s used: It’s precise — it finds real deadlocks without false alarms — and works well when the number of active transactions is moderate (hundreds to low thousands).

Java-style pseudocode: cycle detection via DFS

Here’s a simplified version of what a deadlock detector does internally, written in Java so you can see the logic clearly. (Real database engines implement this in C/C++, but the algorithm is identical.)

import java.util.*;

public class DeadlockDetector {

    // adjacency list: transaction -> set of transactions it is waiting for
    private final Map<String, Set<String>> waitForGraph = new HashMap<>();

    public void addWaitEdge(String waitingTxn, String holdingTxn) {
        waitForGraph.computeIfAbsent(waitingTxn, k -> new HashSet<>())
                     .add(holdingTxn);
    }

    // Returns the cycle (deadlock) if found, otherwise null
    public List<String> detectDeadlock() {
        Set<String> visited = new HashSet<>();
        Set<String> inStack = new HashSet<>();  // nodes in current DFS path

        for (String txn : waitForGraph.keySet()) {
            List<String> path = new ArrayList<>();
            if (dfs(txn, visited, inStack, path)) {
                return path;  // cycle found -- this is your deadlock chain
            }
        }
        return null; // no deadlock
    }

    private boolean dfs(String node, Set<String> visited,
                         Set<String> inStack, List<String> path) {
        if (inStack.contains(node)) {
            path.add(node);
            return true; // found a cycle back to a node already in this path
        }
        if (visited.contains(node)) {
            return false; // already fully explored, no cycle from here
        }

        visited.add(node);
        inStack.add(node);
        path.add(node);

        for (String neighbor : waitForGraph.getOrDefault(node, Set.of())) {
            if (dfs(neighbor, visited, inStack, path)) {
                return true;
            }
        }

        inStack.remove(node);
        path.remove(path.size() - 1);
        return false;
    }
}

How this works: The inStack set tracks nodes currently on the active DFS path. If, while walking through “who’s waiting for who,” we bump into a node that’s already in our current path, we’ve found a loop — a deadlock. This is the exact same technique used to detect cycles in course-prerequisite graphs or dependency graphs in build tools.

7.2 Timeout-based detection

What it is: Instead of building a graph, the database simply says “if a transaction waits longer than X seconds for a lock, assume it might be deadlocked and cancel it.”

Why it’s used: It’s much simpler to implement and has near-zero overhead, which matters for distributed databases where building a global wait-for graph across many servers is expensive.

7.3 Edge-chasing (distributed detection)

What it is: Used in distributed databases (data spread across multiple servers). Instead of one central graph, each server sends small “probe” messages along the wait-for edges. If a probe ever comes back to the server that originally sent it, a cycle (deadlock) is confirmed.

Why it’s used: There is no single machine that can see the entire wait-for graph in a distributed system, so probes let the detection work in a decentralised way, similar to how a chain letter would eventually come back to its original sender if it looped.

7.4 Which databases use what?

Detecting deadlocks after they happen is one strategy. But it’s even better when possible to stop them from happening at all. There are three broad families of strategy: prevention, avoidance, and detection + recovery (which we already covered).

8.1 Prevention: lock ordering

What it is: Force every transaction in your application to acquire locks in the exact same, agreed-upon order (e.g., always lock the row with the smaller ID first).

Why it works: A deadlock requires a circular wait. If everyone always locks resources in the same order, a cycle becomes mathematically impossible — you can’t have A wait for B and B wait for A if both always try to lock A before B.

Practical example: In our Alice/Bob example, instead of always locking “the sender first,” both transactions should lock rows in a consistent order — say, alphabetically by account ID.

// BEFORE (deadlock-prone): locks in "sender, then receiver" order
public void transfer(String fromId, String toId, BigDecimal amount) {
    lockRow(fromId);
    lockRow(toId);
    // ... perform transfer
}

// AFTER (deadlock-safe): always lock in a fixed, consistent order
public void transfer(String fromId, String toId, BigDecimal amount) {
    String first  = fromId.compareTo(toId) < 0 ? fromId : toId;
    String second = fromId.compareTo(toId) < 0 ? toId : fromId;

    lockRow(first);   // always the "smaller" ID first
    lockRow(second);  // always the "larger" ID second
    // ... perform transfer using fromId/toId as needed
}

Now, whether Alice transfers to Bob or Bob transfers to Alice, both transactions lock rows in the same fixed order — Alice’s row first (assuming “Alice” < “Bob” alphabetically) — so the circular wait can never form.

8.2 Avoidance: wait-die and wound-wait schemes

What it is: These are timestamp-based algorithms where every transaction gets a timestamp when it starts. When a transaction requests a lock held by another, the database uses a rule based on which transaction is “older” (started earlier) to decide who waits and who gets cancelled — before a deadlock can even form.

Why this works: Timestamps only ever increase, so a chain of “always prefer the older transaction” or “always prefer to cancel the younger transaction” can never loop back on itself — there’s no way to have a cycle where everyone is “older” than everyone else.

Where it’s used: These schemes are especially popular in distributed databases (Google Spanner, CockroachDB) where building a full wait-for graph across many machines would be too slow. Deciding based on a timestamp comparison is fast and requires no central coordination.

8.3 Avoidance: reduce lock scope and duration

The less time a transaction holds a lock, and the fewer rows it locks, the less chance it has to collide with another transaction. Practical techniques:

8.4 Avoidance: use a single statement instead of multiple

Where possible, combine multiple updates into a single atomic SQL statement, which many databases can execute with less lock contention than the same logic split across multiple round trips.

-- Instead of two separate UPDATE statements from the app (higher deadlock risk):
UPDATE accounts SET balance = balance - 80 WHERE id = 'Alice';
UPDATE accounts SET balance = balance + 80 WHERE id = 'Bob';

-- Consider a single statement using a CASE, which many engines can lock more efficiently:
UPDATE accounts
SET balance = CASE
    WHEN id = 'Alice' THEN balance - 80
    WHEN id = 'Bob'   THEN balance + 80
END
WHERE id IN ('Alice', 'Bob')
ORDER BY id; -- ensures a consistent lock acquisition order

It’s worth stepping back and evaluating the overall trade-off of “detect and recover” versus “prevent and avoid” as two overarching strategies.

9.1 Trade-off summary table

Deadlocks aren’t just a correctness issue — they’re a performance issue too. Here’s how they interact with scale.

10.1 Why deadlocks get worse under load

The probability of a deadlock roughly increases with the square of the number of concurrent transactions touching overlapping data (more precisely, it grows with contention, which itself grows non-linearly with concurrency). A system that sees 1 deadlock per hour at 100 concurrent users might see dozens per minute at 1,000 concurrent users if the workload pattern doesn’t change.

10.2 Hot rows: the real culprit

In practice, deadlocks rarely come from “random” collisions across a huge table. They almost always cluster around a small number of hot rows — popular rows that many transactions want to touch at once. Classic examples: a “total inventory count” row, a popular product’s stock row during a flash sale, or a single “global counter” row.

10.3 Techniques to reduce contention at scale

10.4 Connection pooling and deadlock amplification

A subtle scalability trap: if your application’s connection pool is too small and transactions are long, requests start queueing at the connection-pool level too, on top of database-level locking. This compounds delays and can make deadlock storms far worse, because more transactions pile up waiting for both a connection and a lock.

Deadlocks intersect with high availability in a few important ways, especially in replicated and clustered database setups.

11.1 Deadlocks in replicated systems

In a typical primary-replica setup, writes go to a single primary node, so deadlock detection stays localised to that primary — it doesn’t need to coordinate with replicas. But in multi-primary (multi-master) setups, where more than one node can accept writes, deadlock detection becomes far harder because the wait-for graph is now spread across multiple machines.

11.2 Deadlocks in clustered/distributed databases

Systems like Oracle RAC, Google Spanner, CockroachDB, and YugabyteDB run across multiple nodes. Detecting a deadlock that spans two different nodes (a “global deadlock”) requires either:

• A global wait-for graph — periodically merging local graphs from every node, which adds network overhead and delay.
• Timestamp-based avoidance (wait-die / wound-wait) — sidesteps the need for a global graph entirely, which is why most modern distributed SQL databases lean heavily on this approach.

11.3 How deadlocks affect uptime and failover

A deadlock itself does not bring a database down — it’s resolved in milliseconds. But a deadlock storm (many deadlocks happening rapidly, often during a traffic spike or a bad deployment introducing a new hot row) can look like an outage from the user’s perspective: requests time out, retries pile up, and connection pools exhaust. Good monitoring (covered next) helps distinguish a real outage from a deadlock storm that will self-resolve as load drops.

Deadlocks aren’t primarily a security topic, but there are two angles worth understanding.

12.1 Deadlocks as a denial-of-service vector

A malicious or careless actor with database access could intentionally craft queries that lock resources in conflicting orders on purpose, deliberately triggering repeated deadlocks to degrade performance for other users — a form of internal denial-of-service. This is more relevant in multi-tenant systems where different customers’ code can run queries against a shared database.

12.2 Information leakage through deadlock errors

Deadlock error messages sometimes include details like table names, row identifiers, or the exact SQL statements involved. If these error messages are shown directly to end users (instead of being logged internally and replaced with a generic message), it could leak internal schema details to an attacker probing your application.

You cannot fix what you cannot see. Every production database team should actively monitor for deadlocks, not just handle the errors reactively.

13.1 Key metrics to track

13.2 Built-in tools by database

13.3 Reading a deadlock graph / report

Most databases produce a structured “deadlock graph” showing exactly which two (or more) transactions were involved, which SQL statements they were running, and which locks they held versus wanted. Learning to read one is a core DBA/backend skill. Here’s a simplified example of what MySQL’s InnoDB deadlock output looks like:

------------------------
LATEST DETECTED DEADLOCK
------------------------
*** (1) TRANSACTION:
TRANSACTION 421, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 45, query id 998 updating
UPDATE accounts SET balance = balance + 80 WHERE id = 'Bob'

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 12 page no 4 n bits 72 index PRIMARY
of table 'bank'.'accounts' trx id 421 lock_mode X locks rec but not gap
waiting

*** (2) TRANSACTION:
TRANSACTION 420, ACTIVE 3 sec starting index read
UPDATE accounts SET balance = balance - 50 WHERE id = 'Alice'

*** WE ROLL BACK TRANSACTION (1)

Reading this: two transactions (421 and 420) each hold a lock the other needs. InnoDB decided to roll back transaction (1), i.e. transaction 421 (Bob’s update), letting transaction 420 (Alice’s update) complete.

13.4 Alerting recommendations

• Alert when deadlock rate exceeds a baseline threshold (e.g., more than 5× the normal hourly average).
• Alert on rising p99 lock wait time even before actual deadlocks spike — it’s an early warning sign.
• Send deadlock graphs to a dedicated log channel (not mixed with general app logs) so patterns are easy to spot over time.
• Track deadlocks per deploy — correlating a new spike with a recent code or schema change speeds up root-cause analysis enormously.

How you deploy and configure your database affects how often you’ll see deadlocks, and how easily you can diagnose them.

14.1 Managed cloud databases

14.2 Configuration knobs worth knowing

14.3 CI/CD and schema migrations

Large schema migrations (like adding an index or altering a column on a busy table) can hold long locks and dramatically increase deadlock risk during the deployment window. Modern practice is to use online / non-blocking migration tools (e.g., gh-ost or pt-online-schema-change for MySQL, or built-in concurrent index creation in PostgreSQL with CREATE INDEX CONCURRENTLY) to avoid taking heavy locks during deploys.

Let’s connect deadlocks to some bigger distributed-systems concepts you’ll encounter in interviews and real architecture work.

15.1 CAP theorem and locking

The CAP theorem says a distributed system can only fully guarantee two of three properties at once: Consistency, Availability, and Partition tolerance. Strong locking (needed to prevent lost updates, and which creates deadlock risk) is fundamentally a consistency mechanism. Systems that prioritise consistency (CP systems, like traditional relational databases) accept more locking overhead and deadlock risk, while systems that prioritise availability (AP systems, like many NoSQL databases) often avoid locks and heavy consistency guarantees altogether — and as a trade-off, don’t experience database-level deadlocks the same way, but can suffer other consistency issues like lost updates or conflicting writes that must be resolved later.

15.2 Replication & consensus

Distributed databases that use consensus protocols like Raft or Paxos (used in etcd, CockroachDB, Spanner) elect a leader for each range/shard of data. Writes to that shard are serialised through the leader, which naturally limits deadlock scope to transactions touching the same shard’s leader — though cross-shard transactions (touching multiple leaders) reintroduce the harder distributed deadlock problem, which is why cross-shard transactions are generally more expensive and slower.

15.3 Failure recovery

If a database node crashes while holding locks (mid-transaction), those locks must eventually be released so waiting transactions aren’t stuck forever. This is handled through:

• Write-ahead logs (WAL): On restart, the database replays the log to determine which transactions were incomplete and rolls them back, releasing their locks.
• Lease/heartbeat timeouts: In distributed systems, if a node holding a lock stops sending heartbeats, its locks are eventually considered “abandoned” and released after a timeout, so other nodes aren’t stuck waiting on a dead node forever.

Deadlocks aren’t only a “pure database” problem — they show up in interesting ways once you have APIs and microservices in the picture too.

16.1 Handling deadlocks at the API layer

A well-designed API should never leak a raw database deadlock error to its caller. Instead, the service layer should catch the deadlock exception, retry internally (with backoff), and only return an error to the caller if retries are exhausted.

@Service
public class TransferService {

    private static final int MAX_RETRIES = 3;

    public void transferMoney(String fromId, String toId, BigDecimal amount) {
        int attempt = 0;
        while (true) {
            try {
                doTransfer(fromId, toId, amount); // runs inside a @Transactional method
                return; // success
            } catch (DeadlockLoserDataAccessException e) {
                attempt++;
                if (attempt >= MAX_RETRIES) {
                    throw new TransferFailedException(
                        "Transfer failed after " + MAX_RETRIES + " attempts", e);
                }
                sleepWithBackoff(attempt);
            }
        }
    }

    private void sleepWithBackoff(int attempt) {
        long baseDelayMs = 50L * (1L << attempt);       // exponential backoff
        long jitterMs = (long) (Math.random() * 30);      // jitter to avoid retry storms
        try {
            Thread.sleep(baseDelayMs + jitterMs);
        } catch (InterruptedException ie) {
            Thread.currentThread().interrupt();
        }
    }
}

This pattern (Spring’s DeadlockLoserDataAccessException is shown here as an example, but the same idea applies to any framework/driver) retries a fixed number of times with increasing delays, and eventually gives up and surfaces a clean error rather than retrying forever.

16.2 Deadlocks across microservices (distributed transactions)

When a single business action spans multiple microservices, each with its own database, you can get a “logical deadlock” even without a single shared database wait-for graph. For example: Service A calls Service B synchronously while holding a resource, and Service B calls back into Service A (directly or indirectly) while waiting on the same logical resource.

16.3 Design patterns that avoid this

17.1 Good patterns

17.2 Anti-patterns

17.3 Optimistic locking example (an alternative to heavy row locking)

Instead of locking a row the moment you read it, optimistic locking lets you read freely, and only checks for conflicts when you try to save — using a version number.

-- Table has a "version" column
UPDATE products
SET stock = stock - 1, version = version + 1
WHERE id = 42 AND version = 7;  -- must match the version we read earlier

-- If 0 rows were updated, someone else changed it first -- retry by re-reading and trying again

This approach never holds a lock while the application “thinks,” so it structurally cannot deadlock the way pessimistic (lock-upfront) approaches can — but it does require your application to handle the “someone else got there first” case gracefully with a retry.

18.1 Best practices checklist

18.2 Common mistakes beginners make

19.1 E-commerce: flash sale inventory

During a flash sale, thousands of customers try to buy the same limited-stock item at once. Companies like Amazon and Walmart historically dealt with heavy lock contention (and deadlock risk) on “stock count” rows. The common industry fix is moving away from a single locked “stock” row toward reservation-based systems, sharded counters, or dedicated inventory services that serialise writes through a queue rather than direct row locking by every customer request.

19.2 Banking: concurrent transfers

Banking systems process millions of transfers where the exact scenario in this tutorial (Alice ↔ Bob) happens routinely at massive scale. Financial systems typically combine strict lock ordering (e.g., always lock accounts in ascending account-number order) with careful transaction design and mandatory retry logic, since correctness (never losing or duplicating money) is non-negotiable, and downtime from a deadlock storm is unacceptable for a payment system.

19.3 Ride-sharing: driver matching

Platforms like Uber and Lyft need to atomically assign a specific driver to a specific rider — read the driver’s status, check they haven’t already been assigned elsewhere, and update both driver and ride records together. Under high demand (e.g., during a big event), many concurrent match attempts increase lock-contention risk. A common architectural fix is offloading matching decisions to an in-memory system (rather than doing it all via direct database row locks), then writing the final result to the database in a single fast transaction — minimising the time any lock is held.

19.4 Ticketing: high-demand event sales

Ticket sales platforms (like Ticketmaster-style systems) for extremely popular events face an extreme version of the flash-sale problem — potentially millions of users hitting “buy” on the same small pool of seats within seconds. These systems typically use queueing (a virtual waiting room) to throttle how many requests hit the database at once, dramatically reducing the concurrent contention that would otherwise cause severe deadlock storms.

19.5 Streaming: Netflix-style metadata updates

Large-scale content platforms managing viewing history, recommendations, and metadata across millions of concurrent users lean heavily on techniques discussed earlier: sharding hot counters (like “total views”), using eventually-consistent systems for non-critical data (avoiding heavy locking entirely where strict consistency isn’t required), and reserving strict transactional locking only for genuinely critical operations like billing.

Fast, opinionated answers to the questions that come up first when teams are just starting to internalise what “deadlock” means — followed by a compact summary and the ideas worth carrying away into every design conversation.

Frequently asked questions

Summary

A deadlock is a natural side effect of using locks to keep shared data safe when multiple transactions run at the same time. It happens when two or more transactions form a circular chain of waiting, where each one holds a lock the next one needs. Databases solve this with a mix of detection (building a wait-for graph and searching for cycles, then rolling back a chosen “victim” transaction) and avoidance (like consistent lock ordering or timestamp-based schemes such as wait-die and wound-wait).

At scale, the real enemy isn’t the deadlock mechanism itself — which resolves in milliseconds — but contention on “hot” shared resources, which is best solved architecturally through sharding, queueing, shorter transactions, and thoughtful retry logic in the application layer.