Sinkronisasi Data: Cara Menjaga Dua Sistem Tetap Konsisten
Oleh Apex Horizon Digital
Sinkronisasi data gagal ketika dua sistem boleh mengedit arti yang sama tanpa aturan authority, timing, conflict, deletion, dan recovery. Desain andal dimulai dari tabel source-of-truth tingkat field dan identifier stabil yang dibagikan antarsistem. Desain lalu menentukan cara perubahan bergerak, apa yang terjadi saat kedua sisi berubah, bagaimana retry tetap aman, dan bagaimana owner merekonsiliasi record yang tidak dapat diselesaikan otomatis.
Ringkasan utama
- Tetapkan satu owner berwenang untuk setiap field dan business state yang disinkronkan.
- Perlakukan conflict, deletion, dan delivery tidak pasti sebagai hasil workflow eksplisit.
- Lakukan rekonsiliasi independen agar drift ditemukan walaupun setiap integration run melaporkan sukses.
Bangun tabel source-of-truth
Buat satu baris untuk setiap field atau state yang melewati batas. Catat arti bisnis, system of record, editor yang diizinkan, destination, arah, identifier, validation, update trigger, dan conflict owner. Nama legal pelanggan mungkin milik CRM, status pembayaran milik accounting, dan status fulfillment milik ERP. Jangan menetapkan authority berdasarkan kenyamanan atau API yang paling mudah. Tabel juga harus membedakan data display yang disalin dari nilai yang memicu tindakan finansial atau operasional. Destination dapat menampilkan nilai tanpa diizinkan membuat perubahan asal.
- Identity: internal key, external key, aturan matching, dan owner penyelesaian duplikat.
- Authority: source system, role yang diizinkan, arah write, dan proses override approved.
- Quality: status wajib, format, nilai yang diizinkan, validation, dan tujuan koreksi.
Tentukan arah dan timing perubahan
Pilih apakah setiap nilai bergerak satu arah, dua arah, atau hanya setelah business transition. Sinkronisasi berbasis event dapat mengurangi delay, sedangkan sinkronisasi terjadwal dapat menyederhanakan load dan recovery. Pilihan mengikuti seberapa cepat destination membutuhkan perubahan dan akibat jika data sementara stale. Catat perilaku create, update, dan status transition secara terpisah. Pelanggan yang dibuat di CRM mungkin baru disalin ke accounting setelah field pajak lengkap. Gunakan version, timestamp, atau change token stabil bila didukung, lalu dokumentasikan timezone serta asumsi urutan.
- Flow satu arah: satu sistem memiliki nilai dan destination tidak pernah mengirim edit kembali.
- Flow dua arah: kedua sisi mengedit hanya jika conflict rule terdokumentasi melindungi arti.
- Flow transition: data bergerak setelah validation, approval, posting, atau state change eksplisit.
Tangani conflict dan deletion secara sengaja
Conflict terjadi ketika dua perubahan valid tidak dapat diterapkan bersama. Jangan mengandalkan timestamp terbaru kecuali bisnis menerima kehilangan keputusan sebelumnya dan clock sistem dapat dipercaya. Pilih field ownership, version comparison, atau antrean review yang menampilkan kedua nilai, editor, timestamp, dan dampak downstream. Deletion memerlukan kebijakan sendiri. Hard deletion mungkin tidak tepat untuk record finansial atau audit. Source dapat menandai record inactive, revoked, merged, atau archived, lalu mengirim state tersebut. Tentukan apakah transaksi terkait memblokir deletion dan bagaimana merged identifier dipertahankan untuk history.
- Conflict rule: sistem berwenang, version check, merge yang diizinkan, atau keputusan manusia dengan bukti.
- Deletion rule: hard delete, soft delete, archive, deactivate, merge, atau retain tanpa sync lanjutan.
- Downstream rule: notification, penghapusan akses, transaction block, history retention, dan restoration path.
Buat retry aman dan hasil observable
Setiap perubahan membutuhkan transaction atau event identifier yang bertahan saat retry. Receiving side harus mengenali delivery berulang dan mengembalikan hasil yang ada, bukan membuat record lain. Bedakan validation rejection, kegagalan service sementara, permission failure, dan hasil tidak diketahui. Retry temporary failure dengan delay terbatas, tetapi rekonsiliasi hasil tidak diketahui sebelum mengirim ulang tindakan yang tidak repeatable. Log harus memuat business identifier, source version, target action, attempt, result, dan error category tanpa mengekspos nilai sensitif. Alert harus diarahkan ke owner yang dapat memperbaiki penyebab.
- Idempotency: delivery berulang dari satu perubahan menghasilkan satu business outcome.
- Recovery: safe retry, corrected resubmission, manual resolution, atau rekonsiliasi sebelum tindakan lain.
- Observability: correlation ID, record ID, version, arah, timestamp, result, usia, dan owner.
Rekonsiliasi dan tetapkan ownership operasi
Jalankan perbandingan independen pada jadwal yang ditentukan. Bandingkan count, identifier, field version, total, status, dan record yang berubah sejak checkpoint sebelumnya. Pisahkan source hilang, target hilang, mismatch nilai, duplikat, stale update, dan conflict belum selesai. Setiap kategori membutuhkan owner serta prosedur koreksi. Pantau usia dan recurrence perbedaan, bukan hanya persentase match. OpenAPI Specification dapat mendokumentasikan interface, input, response, dan security scheme, tetapi business authority serta rekonsiliasi tetap keputusan organisasi. Review mapping, credential, API version, ownership, dan deletion policy saat sistem berubah.
- Bukti rekonsiliasi: periode, population, comparison rule, perbedaan, owner, dan resolution status.
- Ownership operasi: process owner, data owner, integration owner, support owner, dan access approver.
- Change control: schema, mapping, rule, credential, endpoint, version, testing, dan rollback review.