A wait-for graph in a database has an edge from transaction T1 to T2 when T1 is blocked waiting on a lock T2 holds. A cycle in this graph is a deadlock. The engine's deadlock detector finds cycles and aborts a victim — preferably the cheapest transaction to roll back. Choosing victims to break all current cycles with fewest aborts is feedback vertex set on the wait-for graph. PostgreSQL, Oracle, and InnoDB all run this loop continuously; they don't compute the optimal FVS (overkill for the few-vertex cycles seen in practice) but the framing is the same. The same pattern shows up in microservice circuit-breaker design: which retries to abort to break a cascade cycle? And in Kubernetes resource scheduling: which pods to evict to clear a resource-deadlock cycle?
21
Deadlock detection
Database engines, OS schedulers, and microservice meshes all watch for cycles. Killing the right node breaks the cycle without taking down the whole system.