2026-09-03 · 6 min read · Rahul Chitturi
- sql
- database
- reliability
A deadlock occurs when concurrent transactions wait on resources held by one another and the database aborts one participant to restore progress. The failed statement is often only where the cycle became visible, not where inconsistent lock order began.
Blindly retrying every database error can duplicate side effects or hide sustained contention. Diagnosis needs the complete transaction, lock evidence, and the application's retry boundary.
Reconstruct the lock cycle
Collect the database deadlock report, normalized statements, transaction start times, isolation level, and affected indexes. Replace customer values with safe fixtures while preserving statement shape and execution order.
- Compare the order in which transactions touch tables and rows
- Check scans caused by missing or unusable indexes
- Find network calls or user work inside open transactions
- Separate deadlocks from lock waits and statement timeouts
Retry the complete unit of work
When the database classifies an error as retryable, roll back and rerun the whole transaction with bounded backoff and jitter. Retrying only the final statement can violate assumptions established by earlier reads.
Make external side effects idempotent or move them after commit through an outbox-style workflow. Cap attempts and expose failures rather than allowing retries to amplify overload.
A Flashman workflow
Use the SQL formatter to compare statement order, timestamp converter to align transaction events, UUID generator for synthetic idempotency keys, and diff to review query-plan or transaction changes.
Load-test opposite update orders, hot rows, missing indexes, timeout boundaries, rollback behavior, duplicate delivery, and sustained contention with the production database engine.