Satu proses bisnis sering menulis lebih dari satu tabel. Invoice memiliki header dan item; penerimaan barang memiliki dokumen dan pergerakan stok. Jika sebagian penulisan berhasil sementara bagian lain gagal, database dapat menyimpan keadaan yang tidak lengkap. Atomic transaction dirancang untuk mencegah kondisi tersebut dalam batas satu koneksi database.
Apa arti “atomik” dalam transaksi database?
Atomik berarti sekumpulan operasi diperlakukan sebagai satu kesatuan. Database memulai transaksi, menjalankan penulisan, lalu melakukan commit hanya ketika seluruh operasi berhasil. Bila satu constraint, tipe, atau koneksi menghasilkan kegagalan sebelum commit, perubahan dalam transaksi tersebut dibatalkan.
Sifat ini berbeda dari sekadar menjalankan node secara berurutan. Urutan menjamin header dicoba sebelum item, tetapi tidak otomatis menghapus header apabila item ketiga gagal. Jaminan rollback berasal dari transaksi database yang aktif pada koneksi yang sama, bukan dari bentuk garis pada kanvas workflow.
Kapan beberapa penulisan harus menjadi satu transaksi?
Mulailah dari invariant bisnis: kondisi apa yang tidak boleh terlihat setengah selesai? Invoice tanpa item mungkin tidak valid. Transfer stok yang hanya mengurangi gudang asal tanpa menambah gudang tujuan juga bermasalah. Sebaliknya, pencatatan audit terpisah mungkin boleh gagal tanpa membatalkan transaksi utama bila organisasi memiliki mekanisme rekonsiliasi lain.
| Pertanyaan | Jika “ya” | Implikasi |
|---|---|---|
| Apakah record saling bergantung? | Kelompokkan | Gunakan satu unit transaksi |
| Apakah semuanya satu koneksi? | ACID memungkinkan | Commit atau rollback bersama |
| Apakah ada API/email? | Bukan bagian ACID DB | Gunakan idempotensi dan rekonsiliasi |
| Apakah database berbeda? | Bukan transaksi lokal | Pertimbangkan Saga |
Contoh workflow invoice header-detail
- Validasi payload.
Pastikan header dan setiap item memenuhi kontrak sebelum penulisan dimulai.
- Buat identitas eksekusi.
UUID sementara dapat menjadi invoice ID yang sama pada header dan child item.
- Tulis header lebih dahulu.
Urutan diperlukan ketika item memiliki foreign key menuju header.
- Iterasi item.
Node Untuk Setiap membawa field induk dan item aktif ke mapping penulisan detail.
- Commit satu batch.
Penulisan ke agent dan koneksi database yang sama dikumpulkan sebagai batch atomik.
NitroNet mengelompokkan penulisan sinkron berdasarkan agent dan koneksi database. Agent menjalankan batch dengan begin, commit, atau rollback. Jika duplicate detail atau constraint lain gagal, seluruh batch pada grup tersebut dibatalkan, lalu informasi error dipetakan ke item dan node bermasalah.
Uji rollback, bukan hanya happy path
Pengujian pertama memastikan header dan seluruh item tersimpan. Pengujian berikutnya harus sengaja membuat item tengah gagal: duplicate key, foreign key tidak valid, nilai null pada kolom wajib, atau check constraint. Setelah respons gagal diterima, periksa database secara langsung dan pastikan tidak ada header maupun item parsial.
Uji juga request ulang. Atomic transaction menjaga konsistensi satu percobaan, tetapi tidak otomatis menjadikan seluruh endpoint idempoten. Bila agent atau koneksi terputus setelah tujuan memproses tetapi sebelum status diterima, retry tetap membutuhkan kunci bisnis atau idempotency key yang stabil.
Kesalahan desain yang sering terjadi
- Menganggap semua node dalam satu workflow otomatis berada dalam satu transaksi.
- Mencampurkan database berbeda atau API eksternal dalam klaim rollback ACID.
- Membuat UUID baru di dalam iterasi sehingga foreign key item tidak sama dengan header.
- Menangani error item tetapi tetap mengirim respons sukses untuk keseluruhan transaksi.
- Tidak memeriksa state database setelah pengujian gagal.
Isolation dan concurrency juga memengaruhi hasil. Dua eksekusi dapat lolos validasi awal lalu berebut unique key atau memperbarui record yang sama. Constraint database tetap diperlukan meskipun workflow sudah memeriksa keberadaan data. Untuk update sensitif, gunakan version field atau kondisi yang mendeteksi perubahan sejak data dibaca, lalu kembalikan konflik yang dapat ditindaklanjuti alih-alih menimpa diam-diam.
Durasi transaksi perlu dijaga singkat. Jangan menahan transaction database sambil menunggu API eksternal, email, approval manusia, atau delay panjang. Lakukan pekerjaan non-database sebelum begin jika aman, lalu kumpulkan mutasi lokal dalam batch pendek. Setelah commit, efek eksternal diproses melalui mekanisme delivery terpisah dengan idempotensi. Pemisahan ini mengurangi lock yang berkepanjangan sekaligus membuat batas konsistensi terlihat bagi operator.
Batas transaksi harus terlihat dalam desain
Penulisan ke koneksi lain menggunakan Saga dan kompensasi. Aksi HTTP atau email bersifat at-least-once dan tidak dapat di-rollback bersama database.
Transaksi atomik mengurangi risiko data parsial, tetapi bukan pengganti validasi, idempotensi, dan observability. Gunakan mode Sandbox untuk memverifikasi jalur gagal dengan data uji. Pelajari pula cara memilih operasi database dan alur agent-centric NitroNet sebelum merancang proses banyak tabel. Dokumentasikan pula bukti hasil rollback.