Menulis dua database dalam satu workflow dapat terlihat seperti transaksi biasa: tulis tujuan pertama, tulis tujuan kedua, lalu rollback bila ada error. Kenyataannya, setiap database memiliki koneksi, transaction manager, status commit, dan kemungkinan gangguan sendiri. Setelah database pertama commit, database lain tidak dapat memutar balik commit tersebut secara ajaib.
Di mana batas transaksi ACID?
Transaksi lokal berlangsung di dalam satu database connection. Begin, seluruh perintah, dan commit atau rollback dikelola oleh database yang sama. Bahkan dua koneksi menuju engine yang sama tidak otomatis berbagi transaction context. Ketika workflow menulis PostgreSQL dan MySQL, tidak ada satu perintah rollback lokal yang menguasai keduanya.
Protokol distributed transaction memang ada pada sebagian teknologi, tetapi dukungan, konfigurasi, dan karakteristiknya tidak universal di seluruh driver dan environment. Platform integrasi tidak boleh mengklaim rollback global hanya karena dapat mengirim perintah ke banyak tujuan.
Mengapa kegagalan lintas database sulit dipastikan?
Gangguan dapat terjadi pada titik yang ambigu. Tujuan kedua mungkin sudah commit, tetapi respons terputus sebelum diterima. Koordinator proses tidak dapat menyimpulkan dari timeout saja apakah operasi belum dijalankan atau sudah selesai. Retry buta dapat menghasilkan duplikasi, sedangkan pembatalan buta dapat menghapus perubahan yang bukan milik eksekusi tersebut.
Constraint dan tipe data juga berbeda. Nilai yang diterima PostgreSQL belum tentu diterima SQL Server atau MongoDB. Karena itu, preflight skema membantu menemukan konflik sebelum eksekusi, tetapi perubahan keadaan antara preflight dan commit masih mungkin terjadi.
Tiga pilihan desain yang jujur
| Pendekatan | Cocok untuk | Batas utama |
|---|---|---|
| Satu database | Data yang wajib atomik | Membutuhkan konsolidasi boundary |
| Eventual consistency | Tujuan dapat menyusul | Perlu status dan rekonsiliasi |
| Saga | Langkah lintas tujuan dengan inverse action | Kompensasi dapat gagal |
Pilihan terbaik sering kali adalah mengecilkan unit atomik. Simpan transaksi utama pada satu system of record, lalu distribusikan proyeksi ke sistem lain. Bila kedua perubahan benar-benar diperlukan, definisikan status “pending synchronization” daripada berpura-pura semua tujuan commit serentak.
Contoh penulisan PostgreSQL lalu MySQL
- Preflight.
Validasi koneksi, tabel, kolom, tipe, dan rencana kompensasi sebelum mutasi.
- Buat correlation ID.
Identitas stabil menghubungkan jurnal dan operasi di kedua tujuan.
- Tulis tujuan pertama.
Catat snapshot atau inverse action yang diperlukan untuk kompensasi.
- Tulis tujuan kedua.
Jika berhasil, tandai Saga selesai; jika gagal, jalankan kompensasi terbalik.
- Rekonsiliasi.
Pastikan status akhir cocok dengan bukti di setiap database, bukan hanya respons jaringan.
Bagaimana jika kompensasi juga gagal?
Kompensasi adalah operasi database baru. Ia dapat menghadapi koneksi offline, constraint baru, atau record yang telah diubah proses lain. Platform integrasi visual menandai kondisi yang belum pulih sebagai status yang memerlukan pemulihan manual. Status tersebut lebih jujur daripada melaporkan rollback sukses ketika bukti konsistensinya belum lengkap.
Tim operasi membutuhkan runbook: siapa meninjau jurnal, bagaimana memverifikasi masing-masing tujuan, kapan retry aman, dan kapan diperlukan keputusan manual. Data sensitif dalam jurnal juga harus dienkripsi serta memiliki kebijakan retensi.
Nilai ekonomi dari desain juga perlu dinilai. Rollback global yang tampak nyaman dapat menambah coupling, waktu pemulihan, storage jurnal, dan kebutuhan operator khusus. Sebaliknya, eventual consistency menambah pekerjaan rekonsiliasi dan keadaan pending. Bandingkan dampak bisnis dari keterlambatan, data parsial, dan koreksi manual; jangan memilih arsitektur hanya berdasarkan jumlah node yang lebih sedikit.
Lakukan game day dengan memutus koneksi pada setiap posisi: sebelum tujuan pertama, setelah commit pertama, ketika tujuan kedua merespons, dan saat kompensasi. Pastikan correlation ID tetap sama, status tidak berubah menjadi sukses secara prematur, dan runbook dapat dijalankan oleh operator yang bukan pembuat workflow. Bukti keadaan database harus menjadi dasar penutupan insiden, bukan sekadar status terakhir di UI.
Tetapkan SLO pemulihan yang realistis untuk status pending dan status yang memerlukan pemulihan manual. Tidak semua perbedaan harus diperbaiki dalam hitungan detik, tetapi setiap kasus memerlukan owner dan batas eskalasi. Dashboard perlu membedakan Saga aktif, kompensasi berjalan, pulih, serta membutuhkan intervensi. Dengan state yang eksplisit, sistem lain tidak perlu menebak konsistensi hanya dari ada atau tidaknya record.
Pertanyaan sebelum memakai transaksi multi-database
- Bisakah satu database menjadi system of record dan tujuan lain bersifat eventual?
- Apakah setiap langkah memiliki kompensasi yang aman dan idempoten?
- Bagaimana membedakan timeout sebelum commit dan timeout setelah commit?
- Siapa yang menangani status
status yang memerlukan pemulihan manual? - Apakah dampak bisnis lebih baik ditangani dengan pending state daripada pembatalan?
orkestrasi transaksi lintas penyimpanan platform integrasi visual menyediakan preflight, jurnal terenkripsi, urutan lintas koneksi, dan kompensasi Saga. Ia bukan transaksi ACID global. Untuk fondasi konsepnya, baca transaksi atomik satu koneksi dan alur agent-centric yang membawa instruksi ke database tujuan.
Pembahasan ini menjelaskan pola industri umum, bukan implementasi produk tertentu. Jika tim sedang membandingkan pilihan, NitroNet dapat dimasukkan sebagai salah satu opsi evaluasi dan tetap perlu diuji dengan kebutuhan, risiko, serta kesiapan operasi organisasi.