DB Transaction #

Dalam web application modern, database bukan sekadar tempat menyimpan data, tetapi jantung dari konsistensi sistem. Hampir semua operasi penting—registrasi user, pembayaran, update saldo, order processing—melibatkan lebih dari satu query database.

Di sinilah database transaction menjadi krusial.

Tanpa transaction, aplikasi berisiko masuk ke kondisi data setengah jadi, inkonsisten, atau bahkan korup. Masalah ini sering tidak langsung terlihat, tetapi efeknya bisa fatal ketika traffic meningkat, concurrency tinggi, atau terjadi error di tengah proses.

Artikel ini membahas:

• Apa itu database transaction dan perannya
• Purpose dan masalah apa yang dihindari
• Apa saja yang seharusnya dan tidak seharusnya ditangani oleh transaction
• Best practice implementasi database transaction di web application

Apa Itu Database Transaction? #

Database transaction adalah sekumpulan operasi database yang diperlakukan sebagai satu kesatuan kerja (unit of work).

Sederhananya:

• Semua operasi berhasil → COMMIT
• Salah satu gagal → ROLLBACK semuanya

Transaction memastikan database tidak pernah berada dalam kondisi setengah berhasil.

Contoh sederhana:

• Kurangi saldo user
• Catat histori pembayaran
• Update status order

Ketiganya harus sukses bersama, atau gagal bersama.

Fundamental: ACID Properties #

Transaction bekerja berdasarkan prinsip ACID, yang menjadi fondasi reliability database relasional.

1. Atomicity #

Semua atau tidak sama sekali

Jika satu query gagal, seluruh perubahan dibatalkan.

2. Consistency #

Data selalu berpindah dari satu state valid ke state valid lainnya

Constraint, foreign key, dan business rule tetap terjaga.

3. Isolation #

Transaction tidak saling mengganggu

Concurrent transaction tidak menyebabkan data saling tumpang tindih secara tidak konsisten.

4. Durability #

Data yang sudah commit tidak akan hilang

Walaupun server crash setelah commit.

Peran Database Transaction dalam Web Application #

Menjaga Konsistensi Data #

Web app hampir selalu bersifat concurrent:

• Banyak user
• Banyak request paralel

Transaction mencegah:

• Double update
• Lost update
• Dirty read
• Phantom data

Sebagai Boundary Business Logic #

Transaction menjadi pembatas yang jelas untuk satu proses bisnis.

Contoh:

• Satu API call = satu transaction
• Satu use case = satu transaction

Ini membuat logika aplikasi lebih mudah dipahami dan diuji.

Error Handling yang Deterministik #

Dengan transaction:

• Error di tengah proses → rollback otomatis
• Tidak perlu cleanup manual

Tanpa transaction, developer sering menulis “compensating logic” yang kompleks dan rawan bug.

Fondasi Data Integrity #

Constraint database (FK, unique, check) bekerja optimal di dalam transaction.

Transaction bukan pengganti constraint, tapi partner yang saling melengkapi.

Purpose Utama Database Transaction #

Mencegah Partial Update #

Tanpa transaction:

• Step 1 sukses
• Step 2 gagal
• Data sudah terlanjur berubah

Dengan transaction:

• Gagal = tidak ada perubahan

Menyederhanakan Recovery #

Rollback jauh lebih aman daripada:

• Manual revert
• Script cleanup
• Hotfix data di production

Mengontrol Concurrency #

Transaction + isolation level:

• Menentukan bagaimana data dibaca
• Mencegah race condition

Menjadi Safety Net #

Transaction adalah last line of defense ketika:

• Bug logic
• Timeout
• Network issue
• Crash di tengah proses

Apa yang Ditangani oleh Database Transaction #

✅ Cocok Ditangani oleh Transaction #

1. Multi-query write operation

   • Insert + update + delete

2. State transition bisnis

   • pending → paid → completed

3. Financial / critical data

   • saldo
   • point
   • quota

4. Relational integrity

   • parent-child insert
   • cascade operation

5. Idempotency protection (bersama unique constraint)

Apa yang Sebaiknya Dihindari di Dalam Transaction #

Ini bagian yang sering salah kaprah.

❌ Operasi I/O Eksternal #

Jangan lakukan ini di dalam transaction:

• HTTP call ke service lain
• Kirim email
• Push notification
• Upload file ke object storage

Alasan:

• Transaction menjadi lama
• Lock database lebih panjang
• Risiko deadlock meningkat

❌ Long Running Logic #

Hindari:

• Loop besar
• Heavy computation
• Sleep / retry

Transaction harus sependek mungkin.

❌ Business Logic yang Bisa Dipisah #

Jika bisa:

• Hitung di luar transaction
• Validasi di awal
• Simpan hasil final di dalam transaction

Transaction ≠ Solusi Semua Masalah #

Beberapa kesalahan mindset:

❌ “Pakai transaction berarti aman”

• Salah isolation level tetap bisa bug

❌ “Semua query harus pakai transaction”

• Read-only query sering tidak perlu

❌ “Transaction menggantikan locking”

• Lock tetap perlu dipahami

Transaction adalah alat, bukan obat mujarab.

Best Practice Database Transaction di Web Application #

Keep Transaction Short #

Open late, commit early

• Jangan buka transaction di awal request
• Jangan commit di akhir request jika tidak perlu

Satu Transaction = Satu Use Case #

Hindari:

• Nested transaction yang tidak jelas
• Transaction lintas layer tanpa kontrol

Gunakan Isolation Level yang Tepat #

Umumnya:

• READ COMMITTED → default aman
• REPEATABLE READ → financial / critical
• SERIALIZABLE → sangat jarang, mahal

Pilih berdasarkan kebutuhan, bukan paranoia.

Selalu Pair dengan Database Constraint #

Transaction tanpa constraint:

• Masih bisa data invalid

Gunakan:

• UNIQUE
• FOREIGN KEY
• CHECK

Jangan Takut Rollback #

Rollback itu:

• Murah
• Aman
• Lebih baik daripada data rusak

Design flow aplikasi dengan asumsi rollback pasti terjadi.

Log di Level yang Tepat #

• Log error sebelum rollback
• Jangan spam log di setiap commit

Transaction error harus observable.

Test Concurrency Scenario #

Unit test saja tidak cukup.

Tambahkan:

• Integration test
• Concurrent request test

Bug transaction sering muncul hanya di load tinggi.

Penutup #

Database transaction adalah pondasi keandalan web application.

Ia tidak terlihat di UI, tidak viral di blog post, tetapi:

• Menentukan apakah sistem bisa dipercaya
• Menentukan apakah data bisa diselamatkan saat error

Web application yang matang biasanya ditandai dengan:

• Transaction boundary yang jelas
• Isolation level yang dipahami
• Logic yang sadar akan rollback

Jika satu hari Anda bertanya:

“Kenapa data kami rusak padahal code-nya kelihatan benar?”

Jawabannya sering berakhir di satu kata:

transaction.