Ketika satu proses harus mengubah lebih dari satu database, tim membutuhkan cara untuk mencatat langkah yang berhasil dan membatalkan dampak yang sudah terjadi bila langkah berikutnya gagal. Saga menyediakan pola tersebut melalui rangkaian transaksi lokal dan tindakan kompensasi, bukan melalui satu rollback ACID global.
Saga mengorkestrasi transaksi lokal
Setiap langkah Saga melakukan transaksi pada satu tujuan. Setelah langkah berhasil, status dan informasi pemulihannya dicatat. Workflow kemudian melanjutkan ke tujuan berikutnya. Bila seluruh langkah berhasil, Saga selesai. Bila salah satu gagal, kompensasi dijalankan untuk langkah yang sudah selesai dalam urutan terbalik.
Pola ini menerima kenyataan bahwa sistem terdistribusi tidak memiliki satu transaction manager universal. Selama proses berjalan, keadaan antar-database dapat berbeda sementara. Desain bisnis perlu menentukan apakah kondisi sementara itu boleh terlihat dan bagaimana konsumen membedakan status pending, completed, compensating, atau recovery required.
Kompensasi bukan selalu delete
Jika Saga membuat record baru, kompensasinya mungkin delete dengan identity yang tepat. Untuk update, kompensasi dapat mengembalikan snapshot nilai sebelum perubahan. Untuk delete, pemulihan memerlukan data yang cukup untuk membuat kembali record beserta relasinya. Terkadang tindakan bisnis yang benar bukan membalik data, tetapi membuat reversal record agar jejak audit tetap utuh.
| Langkah awal | Kandidat kompensasi | Pertanyaan penting |
|---|---|---|
| Insert | Delete by stable ID | Apakah record sudah dipakai proses lain? |
| Update | Restore snapshot | Apakah nilai berubah lagi setelah update? |
| Delete | Reinsert snapshot | Apakah seluruh child dan constraint tersedia? |
| Transaksi finansial | Reversal entry | Apakah audit melarang penghapusan? |
Jurnal adalah sumber bukti pemulihan
Jurnal Saga setidaknya menghubungkan correlation ID, urutan langkah, tujuan, operasi, status, dan materi kompensasi. Informasi tersebut harus cukup untuk melanjutkan pemulihan secara idempoten setelah proses restart. Karena snapshot dapat memuat data sensitif, jurnal harus dienkripsi, dibatasi aksesnya, dan dihapus mengikuti retensi yang disepakati.
Platform integrasi visual membuat jurnal kompensasi terenkripsi untuk orkestrasi transaksi lintas penyimpanan dan menjalankan kompensasi otomatis tanpa meminta pengguna merancang query balik untuk setiap langkah. Preflight memeriksa skema sebelum eksekusi. Otomatisasi ini mengurangi konfigurasi, tetapi tidak mengubah hukum sistem terdistribusi: keadaan tujuan tetap perlu diverifikasi.
Contoh: transaksi penjualan dan database laporan
- Tulis transaksi utama.
Database transaksi menyimpan invoice dengan correlation ID yang stabil.
- Tulis proyeksi laporan.
Database reporting menerima ringkasan yang diperlukan, bukan seluruh data sensitif.
- Tujuan kedua gagal.
Saga menghentikan langkah berikutnya dan membaca jurnal langkah pertama.
- Jalankan kompensasi.
Perubahan pertama dibalik menggunakan identitas atau snapshot yang direkam.
- Verifikasi akhir.
Status selesai hanya diberikan setelah hasil kedua tujuan dan jurnal konsisten.
Dalam banyak arsitektur, database laporan sebenarnya boleh menyusul. Eventual consistency dan retry terukur dapat lebih sederhana daripada membatalkan transaksi penjualan. Saga sebaiknya dipilih karena invariant bisnis, bukan semata-mata karena workflow menyentuh dua database.
Saat kompensasi tidak selesai
Jaringan dapat mati ketika kompensasi berjalan, atau record telah berubah oleh proses lain. Platform integrasi visual menandai Saga sebagai status yang memerlukan pemulihan manual ketika pemulihan otomatis belum dapat dibuktikan selesai. Operator perlu meninjau correlation ID, status langkah, dan keadaan aktual tujuan sebelum retry atau koreksi manual.
- Jangan mengubah status menjadi sukses hanya karena error awal sudah tertangkap.
- Buat kompensasi idempoten agar eksekusi ulang tidak merusak data.
- Pisahkan kewenangan otomatis dari keputusan bisnis berisiko tinggi.
- Siapkan alert dan runbook untuk setiap status yang membutuhkan pemulihan.
Tentukan siapa yang boleh menginisiasi dan menyelesaikan pemulihan. Kompensasi otomatis untuk data operasional berisiko rendah berbeda dari reversal finansial, pelepasan stok, atau pembatalan dokumen legal. Langkah tertentu dapat memerlukan approval atau hanya menghasilkan tugas bagi petugas berwenang. Workflow harus berhenti pada boundary tersebut, membawa bukti yang cukup, dan tidak mengambil keputusan domain yang tidak didelegasikan.
Pantau umur Saga, langkah terakhir yang selesai, jumlah retry kompensasi, dan jumlah status yang memerlukan pemulihan manual. Metrik ini lebih berguna daripada hanya menghitung workflow gagal karena menunjukkan beban pemulihan yang tertahan. Lakukan rekonsiliasi berkala antara jurnal dan tujuan agar Saga yang tidak bergerak tidak tersembunyi. Retensi jurnal harus cukup untuk investigasi dan pemulihan, tetapi tidak menyimpan snapshot sensitif lebih lama dari kebutuhan.
Kapan Saga tepat digunakan?
Jika kompensasi tidak dapat didefinisikan atau efek melibatkan API/email eksternal, gunakan idempotensi, status pending, dan rekonsiliasi; jangan menjanjikan rollback menyeluruh.
Sebelum mengaktifkan workflow, uji kegagalan pada setiap urutan langkah dan uji kegagalan kompensasi. Mulai dari penjelasan batas rollback lintas database dan ACID satu koneksi agar pilihan arsitektur tetap jujur.
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.