Course contentsShow
← Databases & SQL
Lesson 825 of 1,9537. Transaction ManagementFree lesson

Deadlock Scenarios in Distributed Systems

Simulate wait-for-graph collisions across multiple microservices or database shards.

In this lesson, you will learn how transaction dependencies across independent database shards or microservices can create a "wait-for" cycle that no single node can detect on its own.

The Invisible Circle

In a single database, the engine maintains a wait-for-graph—a map showing which transaction is waiting for a lock held by another. In a distributed system, this graph is fragmented.

Imagine you have two microservices, Service A (managing User Balances) and Service B (managing Inventory). A distributed transaction involves updating both.

  1. Transaction 1 locks a record in Service A and then requests a lock in Service B.
  2. Transaction 2 locks a record in Service B and then requests a lock in Service A.

Because Service A doesn't know about the lock held by Transaction 2 in Service B, and Service B doesn't know about the lock held by Transaction 1 in Service A, neither service sees a deadlock. Both transactions sit idle, waiting indefinitely for the other to release resources. This is a Distributed Deadlock.

Visualizing the Collision

We can represent the "wait-for" relationship as a directed graph where an edge represents "is waiting for":

  • Service A: T1 -> T2 (T1 is waiting for T2)
  • Service B: T2 -> T1 (T2 is waiting for T1)

Locally, each service only sees a simple dependency. Globally, when you connect these paths, you create a cycle: T1 -> T2 -> T1.

Managing the Gap

Since there is no central authority to observe the full graph, we often rely on Timeouts. If a transaction waits longer than a defined threshold for a resource across a network boundary, the system assumes a deadlock has occurred. The system will then abort the transaction, release its locks, and trigger a retry. While this is less efficient than instant deadlock detection, it is the most practical way to resolve cycles that span across independent distributed boundaries.

Key Takeaway: Distributed deadlocks occur because local resource managers are blind to lock dependencies on remote nodes, making timeouts the primary mechanism for breaking these invisible circular waits.