Replikasi logis vs ETL batch: memilih gaya sinkronisasi

Masalah apa yang kita selesaikan ketika kita “sinkronkan data”?

Tim menyalin data antar sistem karena pekerjaan jarang terjadi di satu tempat saja. Penjualan mungkin ada di CRM, pembayaran di alat tagihan, dan operasional di dashboard internal. Support butuh gambaran lengkap tanpa bolak-balik antar alat, dan pemimpin ingin laporan yang mencerminkan apa yang benar-benar terjadi.

“Sinkron yang dapat dipercaya” mudah dijelaskan tapi sulit dipertahankan: catatan yang tepat tiba, tidak ada yang penting yang hilang, dan pembaruan muncul cukup cepat agar berguna. “Cukup cepat” tergantung tugas. Pengecekan fraud mungkin perlu hitungan menit. Laporan keuangan bulanan bisa mentolerir jam.

Ketika sinkron gagal, biasanya terlihat sebagai catatan hilang, duplikat, field kadaluarsa, atau pembaruan parsial (mis. header order muncul tapi item baris tidak).

Model mental yang berguna adalah event vs snapshot.

Event adalah perubahan individual: “Order #1842 dibuat,” “status berubah menjadi shipped,” “refund diterbitkan.” Pendekatan change-data cenderung memindahkan event dan bisa mendukung perilaku hampir real-time.

Snapshot adalah salinan terjadwal: “setiap malam, salin pesanan kemarin.” ETL batch sering bekerja seperti ini. Lebih sederhana, tetapi data jadi kurang segar.

Sebagian besar argumen tentang replikasi logis vs ETL batch sebenarnya soal pilihan ini: apakah Anda butuh event berjalan terus, atau snapshot berkala sudah cukup untuk membuat orang percaya pada apa yang mereka lihat?

Replikasi logis dan ETL batch, dijelaskan sederhana

Replikasi logis berarti database sumber mengirim aliran perubahan saat terjadi. Alih-alih menyalin tabel utuh, ia memublikasikan “baris ditambahkan,” “baris diperbarui,” atau “baris dihapus.” Tujuan menerapkan perubahan itu secara berurutan, sehingga tetap selaras erat dengan sumber.

ETL batch berarti Anda mengambil snapshot sesuai jadwal. Sebuah job mengekstrak data (seringkali “semua sejak run terakhir”), mentransformasikannya bila perlu, dan memuat ke tujuan. Jika replikasi terasa seperti pembaruan langsung, ETL batch terasa seperti memeriksa setiap jam (atau setiap malam) dan mengejar ketertinggalan.

Biasanya mereka berjalan di tempat berbeda. Replikasi duduk dekat log perubahan database dan berjalan terus-menerus. ETL batch biasanya job terjadwal yang berjalan, berhenti, lalu berjalan lagi.

Bagaimanapun caranya, Anda tetap harus menjawab pertanyaan kepercayaan yang sama:

• Bagaimana delete direpresentasikan agar tujuan tidak menyimpan baris “hantu”?
• Apa yang terjadi jika perubahan yang sama tiba dua kali (idempoten)?
• Bagaimana Anda menjaga urutan tetap benar ketika banyak baris berubah cepat?
• Bagaimana Anda menghindari kehilangan perubahan selama restart atau redeploy?
• Bagaimana Anda mendeteksi celah, bukan hanya “job sukses”?

Contoh: sebuah order dibuat, lalu statusnya berubah dari “pending” ke “paid”, lalu di-refund. Replikasi mengirim tiga event perubahan. Snapshot harian mungkin hanya menangkap status akhir kecuali Anda merancang proses batch untuk mempertahankan status antara.

Kesegaran dan latensi: seberapa dekat ke waktu nyata yang Anda butuhkan?

Sebelum membandingkan replikasi dan ETL batch, definisikan “cukup segar” dalam istilah bisnis. Mulailah dengan angka: “support bisa bekerja dengan data berumur sampai 5 menit,” atau “keuangan oke dengan total kemarin.”

Kesegaran adalah usia data saat seseorang menggunakannya. Latensi adalah jeda antara perubahan di sumber dan perubahan yang sama muncul di tujuan. Anda bisa punya latensi rata-rata rendah tapi tetap mendapatkan data “tua” jika sink sering berhenti.

Dari mana latensi sebenarnya berasal

Bahkan sink sederhana menumpuk beberapa penundaan: capture (kapan Anda mengetahui perubahan), transit (memindahkan data), processing (transformasi dan deduping), dan apply (menulis dan mengindeks di tujuan).

Aliran konstan (replikasi atau mikro-batch sering) menghasilkan kesegaran yang lebih stabil, tapi Anda mengoperasikan sink sepanjang hari. Batch terjadwal lebih mudah dipahami, tetapi menciptakan lonjakan beban: beban berat jam 2:00 pagi, lalu data menjadi kadaluarsa sampai run berikutnya.

Hampir real-time membantu saat orang membuat keputusan cepat atau pelanggan melihat hasilnya. Dashboard support harus menunjukkan order baru cepat supaya agen tidak menjanjikan sesuatu yang ternyata tidak tersedia. Di sisi lain, jika penggunaan utama adalah laporan mingguan atau penagihan bulanan, mendorong setiap pembaruan kecil seketika menambah kompleksitas tanpa meningkatkan hasil.

Cara praktis memilih:

• Siapa yang menggunakan data yang disinkronkan, dan keputusan apa yang mereka buat?
• Apa yang rusak jika data berumur 15 menit?
• Berapa biaya menjalankan sink secara terus-menerus (infrastruktur dan waktu on-call)?
• Kapan tujuan paling sepi?
• Kesegaran apa yang akan Anda janji-kan (dan komunikasikan)?

Pemulihan kegagalan: kembali ke keadaan benar setelah sesuatu rusak

Sink jarang gagal secara dramatis. Mereka gagal dengan cara kecil dan membosankan: server restart, gangguan jaringan memutus koneksi, atau job crash di tengah load. Tujuannya bukan “tidak pernah gagal.” Tapi “pulih ke keadaan akhir yang benar.”

Mode kegagalan umum meliputi outage sumber, outage tujuan, job crash saat proses, atau data buruk yang melanggar constraint.

Dengan replikasi logis, pemulihan biasanya berarti memutar ulang perubahan dari posisi yang disimpan (sering offset log). Jika tujuan turun, perubahan antre sampai tujuan kembali, lalu dilanjutkan sesuai urutan. Itu bersih jika Anda juga mengelola replication slot (atau ekuivalen) sehingga tidak tumbuh tanpa batas selama outage panjang.

Dengan ETL batch, pemulihan biasanya berarti menjalankan ulang jendela waktu (mis. “reload kemarin” atau “reload 2 jam terakhir”). Itu sering sederhana secara operasional, tapi logika load Anda harus aman dijalankan dua kali.

Pemecah kepercayaan terbesar adalah penulisan parsial. Crash setelah menulis 70% batch bisa meninggalkan duplikat atau baris hilang kecuali Anda merencanakannya. Pola yang membantu di kedua gaya:

• Buat load idempoten sehingga menerapkan input yang sama dua kali berakhir dalam keadaan yang sama.
• Prefer upsert yang menggunakan primary key stabil.
• Majukan penanda “last processed” hanya setelah commit sukses.
• Simpan baris yang ditolak di tempat yang bisa Anda inspeksi dan putar ulang.

Backfill (mengulangi sejarah) di situlah rasa sakit muncul. ETL batch sering menang ketika Anda perlu memproses ulang sebulan data karena rerun sudah bagian dari desain. Replikasi juga bisa backfill, tapi biasanya jalurnya terpisah (snapshot dulu, lalu apply perubahan), jadi layak diuji sebelum benar-benar diperlukan.

Contoh: jika sink orders crash setelah menulis line items tapi sebelum menulis header, load berbasis upsert dengan satu transaksi per order (atau per batch) mencegah order setengah-sink tertinggal.

Evolusi skema: apa yang terjadi saat model data berubah?

Perubahan skema adalah tempat banyak sink diam-diam kehilangan kepercayaan. Pipeline bisa terus berjalan sementara makna data berubah di bawahnya. Replikasi bisa rusak di level database, sementara ETL sering rusak lebih lambat di transformasi dan laporan.

Perubahan aditif paling mudah: kolom baru, tabel baru, field opsional baru. Biasanya bekerja jika konsumen menganggapnya sebagai “tambahan” dan default masuk akal. Jebakannya adalah menganggap setiap konsumen downstream akan memperhatikan field baru atau tahu bagaimana backfill.

Perubahan yang memecah risiko besar: rename, perubahan tipe, kolom dihapus, atau perubahan arti nilai. Ini bisa gagal cepat (error job) atau gagal perlahan (data sampai tapi salah).

Cara berevolusi dengan aman

Jaga perubahan kompatibel cukup lama untuk migrasi:

• Versi skema atau payload (v1, v2) sehingga lama dan baru bisa coexist.
• Jalankan periode kompatibilitas di mana field lama dan baru keduanya ada.
• Backfill sebelum mengganti logika yang bergantung pada bentuk baru.
• Hapus field hanya setelah memastikan tidak ada yang membacanya.

Di mana mapping sering rusak

Kebanyakan kerusakan nyata terjadi di lem antara sistem. Contoh: ETL Anda menggabungkan orders ke customers dengan customer_id. Jika itu di-rename jadi client_id, join bisa berubah menjadi match null dan masih menghasilkan baris.

Perhatikan titik rapuh: cast tipe, join yang menganggap key tak pernah berubah, dan aturan downstream seperti “status salah satu dari nilai ini.”

Keamanan dan kepemilikan: siapa yang boleh menyinkronkan apa?

Pertanyaan keamanan mirip di kedua pendekatan, tapi risiko muncul di tempat berbeda. Replikasi sering berjalan terus dengan akses baca luas ke perubahan. ETL batch berjalan terjadwal, tapi mungkin menarik potongan data lebih besar sekaligus. Di kedua kasus, usahakan permission sekecil mungkin yang masih membuat sink berfungsi.

Gunakan akun layanan khusus, bukan login orang. Beri akses read-only hanya ke tabel, kolom, atau view yang diperlukan, dan batasi dari mana ia boleh terkoneksi. Jika mungkin, buka “sync view” khusus yang sudah memfilter data yang tidak boleh dilihat tujuan.

Field sensitif sering mengejutkan tim. Meskipun tujuan butuh sebuah record, mungkin tidak butuh semua isinya. Tentukan lebih awal apakah akan menghilangkan, memask, atau men-token-kan detail kontak pribadi, info pembayaran, atau catatan internal. Enkripsi data dalam transit, dan simpan rahasia di secret store yang tepat, bukan di konfigurasi pipeline.

Kepemilikan mencegah argumen tak berujung nanti:

• Pilih sumber kebenaran untuk setiap field (bukan hanya setiap tabel).
• Tentukan apakah tujuan boleh menulis balik.
• Putuskan bagaimana konflik ditangani (last write wins, abaikan edit target, review manual).
• Tetapkan aturan retensi untuk data yang disalin di tujuan.

Audit adalah potongan terakhir dari kepercayaan. Anda harus bisa menjawab: siapa mengakses data, apa yang berubah, dan kapan itu mendarat. Praktik sederhana ialah membawa id run sink yang terlacak dan timestamp sehingga Anda bisa menelusuri update ujung-ke-ujung.

Apa yang dipantau supaya sink tetap dapat dipercaya

Sink hanya berguna jika Anda bisa mempercayainya pada hari Selasa acak. Terlepas dari pendekatan, pemantauan harus memberi tahu seberapa tertinggal Anda, seberapa sering gagal, dan apakah angka masih masuk akal.

Tiga sinyal kesehatan harian:

• Lag/latensi: seberapa jauh tujuan tertinggal dari sumber
• Tingkat error: kegagalan, retry, dan record yang dikirim ke dead-letter atau bucket “failed rows”
• Throughput: baris atau event yang diproses per menit, plus penurunan mendadak ke hampir-nol

Lalu tambahkan beberapa cek kualitas data yang menangkap masalah diam-diam. Pilih beberapa tabel penting (orders, invoices, tickets) dan validasi mereka dengan cara yang bisa diulang. Jika kemarin ada 1.240 orders di sumber, tujuan seharusnya tidak punya 1.180 kecuali Anda tahu alasannya.

Cek yang biasanya menutup banyak kasus:

• Hitungan baris per hari (atau per jam untuk feed kritis)
• Total yang harus cocok (jumlah nominal, jumlah order berbayar)
• Rasio null pada field wajib (email, status, timestamp)
• Keunikan untuk key (tidak ada order_id duplikat)
• “Delete truth”: record yang dibatalkan atau dihapus juga hilang (atau diberi tanda) di downstream

Masalah konsistensi sering tersembunyi di celah: update yang datang terlambat, delete yang hilang, atau event yang diterapkan tidak berurutan. Lacak timestamp tertua yang belum diproses, dan sampling berkala untuk memastikan versi terbaru ada.

Untuk alerting, buat sederhana dan dapat ditindaklanjuti. Tetapkan ambang (mis. lag > 15 menit, tingkat error > 1%, throughput di bawah baseline selama 10 menit) dan miliki runbook yang menjawab: apa yang diperiksa pertama, cara replay yang aman, dan cara memastikan kembali ke keadaan benar.

Langkah demi langkah: bagaimana memilih pendekatan sink yang benar

Jelas soal siapa yang akan menggunakan data. Laporan keuangan, dashboard support, dan aturan harga otomatis sama-sama mengonsumsi tabel yang sama dengan cara berbeda. Jika keputusan sensitif waktu, data terlambat bukan sekadar mengganggu—itu bisa salah.

Proses keputusan sederhana:

1. Nama-kan konsumen dan keputusan mereka. Daftar layar, laporan, dan proses yang bergantung pada sink dan apa yang mereka pengaruhi.
2. Tetapkan target, bukan kesan. Sepakati kesegaran (detik, menit, jam), ketepatan (error yang dapat diterima), dan biaya (infrastruktur, waktu engineering, beban operasional).
3. Pilih pola paling sederhana yang memenuhi target. Gunakan replikasi ketika Anda butuh hampir real-time dan capture perubahan yang dapat diprediksi. Gunakan mikro-batch ketika “setiap beberapa menit” cukup. Gunakan batch malam untuk pelaporan dan snapshot historis. Hybrid umum.
4. Rencanakan pemulihan. Putuskan sejauh mana Anda bisa memutar ulang, bagaimana menjalankan backfill, dan bagaimana load tetap idempoten.
5. Definisikan cek kepercayaan dan kepemilikan. Pilih validasi yang membuktikan kesehatan (hitungan, total, last-updated time, spot checks) dan tentukan siapa yang dipaging dan siapa yang memperbaiki data.

Contoh konkret: jika support butuh status order saat berbicara dengan pelanggan, menit penting, jadi replikasi atau mikro-batch cocok. Jika finance butuh angka pendapatan harian, batch malam sering cukup.

Kesalahan umum yang membuat data sinkron tidak dapat dipercaya

Perangkap terbesar adalah menganggap data “segar” otomatis berarti “benar”. Pipeline bisa berjarak beberapa detik dan tetap salah karena join berubah, filter ditambahkan, atau baris terduplikat. Tanpa validasi, seringkali Anda tidak menyadarinya sampai dashboard tampak aneh atau pelanggan mengeluh.

Delete adalah miss umum lain. Baik replikasi maupun ETL perlu rencana jelas untuk apa yang dimaksud dengan “dihapus”. Jika Sistem A hard-delete record tapi Sistem B hanya insert dan update, laporan akan menyimpang seiring waktu. Soft-delete sama rumitnya jika sink tidak membawa flag dan timestamp delete.

Kesalahan yang sering muncul berulang:

• Menganggap kesegaran sebagai tujuan utama dan melewatkan hitungan dasar, total, dan spot check
• Menyinkronkan insert dan update, tapi tidak delete, merge, atau status non-aktif
• Mem-hardcode mapping field yang rusak diam-diam saat kolom di-rename, dibagi, atau berubah tipe
• Tidak punya rencana backfill saat data historis perlu koreksi
• Alert hanya pada kegagalan job, bukan lag, data yang hilang, atau drift lambat

Contoh: CRM Anda menandai pelanggan sebagai “inactive” bukannya menghapusnya. ETL Anda hanya menyalin pelanggan dengan status = active. Sebulan kemudian, laporan pendapatan tampak benar, tapi metrik retensi terinflasi karena pelanggan inactive tidak pernah tersalin (atau tidak pernah dihapus). Semua terlihat segar, tetapi kebenaran sudah salah.

Daftar periksa cepat sebelum Anda menyatakan sink “selesai”

Sepakati “selesai” dengan angka, kepemilikan jelas, dan pemulihan terbukti. Sink yang tampak baik di hari pertama bisa menyimpang saat perubahan nyata dan kegagalan nyata mulai terjadi.

• Janji kesegaran ditulis. Definisikan delay target, kapan diukur, dan apa yang terjadi jika terlewat.
• Sumber kebenaran eksplisit. Untuk field kunci (status, harga, email pelanggan), dokumentasikan sistem mana yang menang dan apakah update satu arah atau dua arah.
• Pemulihan diuji ujung-ke-ujung. Simulasikan kegagalan dan konfirmasi bisa replay atau rerun tanpa duplikat atau baris hilang.
• Aturan perubahan skema ada. Tentukan siapa yang menyetujui perubahan, bagaimana roll-out, dan bagaimana menangani rename, perubahan tipe, dan kolom yang dihapus.
• Pemantauan dapat ditindaklanjuti. Lacak lag, tingkat error, dan cek data inti, dengan alert yang memberi tahu tugas berikutnya bagi on-call.

Cek realitas: jika delivery_instructions ditambahkan ke orders, proses Anda harus jelas apakah itu tersink otomatis, gagal keras, atau diabaikan dengan aman.

Contoh realistis: menyinkronkan order antara dua sistem

Bayangkan perusahaan dengan order disimpan di PostgreSQL. Dua tim butuh data itu: Support butuh dashboard live untuk menjawab “di mana order saya?”, dan Finance butuh angka harian stabil untuk close dan pelaporan.

Mereka memakai pendekatan campuran daripada memaksa satu alat memenuhi semuanya.

Untuk Support, mereka memakai replikasi logis sehingga order baru dan update status muncul cepat di database yang dioptimalkan baca yang menggerakkan dashboard. Untuk Finance, mereka menjalankan ETL batch sekali sehari setelah jam kerja. Itu memuat order final ke data warehouse pelaporan, menerapkan aturan bisnis (pajak, diskon, refund), dan menghasilkan snapshot harian yang tidak berubah saat mereka bekerja.

Lalu terjadi perubahan skema: tim produk menambahkan refund_reason. Support ingin itu segera. Replikasi bisa meneruskan kolom baru dengan cepat, sementara job batch bisa memperlakukannya sebagai opsional dulu (default “unknown”) sampai logika pelaporan siap.

Suatu hari tujuan Support down selama 3 jam. Saat kembali, replikasi mengejar dari posisi yang disimpan. Langkah kunci bukan hanya “lanjut lagi,” tapi “benar”: mereka memverifikasi hitungan order untuk jendela outage dan melakukan spot-check beberapa order terbaru ujung-ke-ujung.

Setiap pagi mereka memeriksa beberapa sinyal singkat sebelum mempercayai angkanya: lag replikasi, hitungan order sumber vs tujuan untuk 24 jam terakhir, duplikat di tabel finance, keberhasilan batch plus baris yang dimuat per run, dan sampel kecil order bernilai tinggi yang diverifikasi di kedua sistem.

Langkah selanjutnya: buat sink terlihat dan mudah dioperasikan

Setelah memilih pendekatan (atau hybrid), pekerjaan nyata adalah membuat sink sesuatu yang bisa dipercaya orang setiap hari. Pilih satu tujuan terukur dan perlakukan itu seperti metrik produk. Untuk sebagian besar tim, tujuan pertama adalah kesegaran (seberapa baru datanya) atau akurasi (seberapa sering salah).

Mulailah kecil: satu tabel, satu stream event, atau satu alur kerja penting (seperti orders atau tickets). Stabilkan jalur itu, lalu salin polanya. Memperbesar sebelum Anda bisa mendeteksi dan memperbaiki masalah dengan cepat membuat kekacauan lebih besar, lebih cepat.

Tampilan “status sink” praktis untuk tim non-teknis biasanya mencakup lag saat ini vs target, waktu sink terakhir sukses, percobaan terakhir yang gagal, volume yang diproses hari ini vs rentang yang diharapkan, dan catatan singkat apa yang harus dilakukan saat status merah.

Jika Anda ingin membangun layar admin internal seperti ini dengan cepat, platform no-code seperti AppMaster (appmaster.io) dapat membantu Anda mengirim tampilan pemantauan dan menyesuaikannya saat kebutuhan berubah, tanpa menulis ulang semuanya ketika skema atau alur kerja berevolusi.