Bagaimana Anda mencegah deadlock dengan ribuan transaksi bersamaan?

Question

IT Interview Practice · Accepted Answer

**Ambil lock dalam urutan global yang konsisten, jaga transaksi tetap pendek, turunkan isolation di mana aman, dan retry pihak yang kalah ketika deadlock tetap terjadi.** Sebuah deadlock adalah siklus: transaksi A menahan baris 1 dan menunggu baris 2, sementara B menahan baris 2 dan menunggu baris 1 — tidak ada yang bisa lanjut, jadi DB membunuh salah satu.

## Siklus yang harus Anda putus

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## Strategi

- **Urutan lock yang konsisten.** Jika setiap transaksi selalu mengunci baris dalam urutan yang sama (mis. primary key menaik), sebuah siklus menjadi mustahil — A dan B keduanya mengambil baris 1 dulu, jadi salah satu sekadar menunggu. Ini adalah tuas terbesar. Bug klasik: sebuah transfer uang yang mengunci akun dalam urutan `(from, to)` deadlock dengan transfer sebaliknya; selalu kunci berdasarkan `min(id), max(id)`.
- **Transaksi pendek.** Tahan lock sesingkat mungkin — lakukan validasi, panggilan jaringan, dan baca **sebelum** `BEGIN`, lalu kunci, tulis, dan `COMMIT` dengan cepat. Transaksi panjang memperlebar jendela untuk siklus dan lock wait.
- **Turunkan isolation di mana aman.** `SERIALIZABLE` mengambil lebih banyak/range lock dan lebih sering deadlock; `READ COMMITTED` (default Postgres) mengunci lebih sedikit. Gunakan isolation terlemah yang masih memenuhi correctness.
- **Retry saat deadlock.** Deadlock bersifat sementara. Tangkap error deadlock (Postgres `40P01`, MySQL `1213`) dan retry seluruh transaksi dengan backoff kecil. Sebagian kontensi tak terhindarkan pada skala, jadi retry adalah jaring pengaman, bukan pengganti pengurutan.

## Perspektif wawancara

Pewawancara memeriksa apakah Anda tahu deadlock **dicegah melalui desain, bukan sekadar ditangkap**. Menyebut "retry" saja adalah jawaban lemah — jawaban hebat memimpin dengan **urutan lock yang konsisten** dan **transaksi pendek**, lalu menambah retry untuk sisanya. Jebakan umum: mengasumsikan app harus mendeteksi deadlock; dalam praktik **DB mendeteksi siklus dan membatalkan satu korban** untuk Anda — tugas Anda adalah pengurutan plus loop retry.

**Trade-off:** pengurutan ketat bisa sulit ketika pola akses dinamis atau membentang beberapa tabel; isolation lebih rendah berisiko anomali (non-repeatable read) yang harus Anda pikirkan. Loop retry harus **idempotent** dan terbatas, atau konflik panas berubah menjadi badai retry. Pencegahan deadlock sesungguhnya adalah disiplin lock plus retry terbatas, bukan satu peluru perak.

Siklus yang harus Anda putus

Strategi

Perspektif wawancara

Pertanyaan terkait