Belajar Debezium - Cross-Region & Hybrid Topologies

#Pendahuluan

Organisasi modern tidak lagi menyimpan seluruh datanya dalam satu region atau satu cloud. Data tersebar di beberapa region, sebagian di on-premise, sebagian di cloud. Episode 14 ini membahas bagaimana Debezium menjadi jembatan replikasi antar region dan antar lingkungan tersebut.

Tantangan terbesar topologi lintas region bukan pada connector-nya, melainkan pada karakteristik jaringan: latency tinggi, bandwidth terbatas, dan risiko koneksi terputus. Desain pipeline harus memperhitungkan semuanya sejak awal, bukan sebagai afterthought.

#Mereplikasi Data Antar Region dengan Debezium

Replikasi antar region mengikuti pola hub and spoke: database di tiap region menghasilkan event yang dikirim ke Kafka pusat, atau ke Kafka lokal dulu lalu diteruskan. Pola yang umum:

region-a DB ──► Debezium ──► Kafka A ──┐
region-b DB ──► Debezium ──► Kafka B ──┴──► Kafka pusat (aggregasi)

Setiap region memakai topic.prefix yang unik agar event tidak bertabrakan saat digabung di Kafka pusat. Untuk aggregasi antar cluster, gunakan MirrorMaker atau Cluster Linking alih-alih menjalankan satu cluster Kafka yang membentang lintas region — replikasi async jauh lebih toleran terhadap latency.

#Arsitektur Hybrid Cloud dan Hybrid Database

Tidak semua sumber data ada di cloud. Database on-premise bisa terhubung ke cloud lewat Debezium Server, runtime ringan yang menjalankan connector tanpa Kafka Connect:

debezium.source.connector.class=io.debezium.connector.postgresql.PostgresConnector
debezium.source.database.hostname=db-onprem.internal
debezium.source.database.port=5432
debezium.source.topic.prefix=dbserver-onprem
debezium.sink.type=kafka
debezium.sink.kafka.producer.bootstrap.servers=kafka-cloud:9092

Konfigurasi di atas menjalankan Debezium di jaringan on-premise dan mengirim event ke Kafka di cloud. debezium.sink.type menentukan tujuan — bisa Kafka, Pulsar, atau sistem lain. Hybrid database berarti mencampur sumber seperti MySQL lama dan cloud-native database; selama keduanya menyediakan log, Debezium bisa menangani keduanya.

#Pertimbangan Latency dan Topologi Jaringan

Replikasi lintas region selalu async dan dipengaruhi latency. Prinsip yang perlu dipahami:

• Latency end-to-end minimal sama dengan latency jaringan antar region.
• Event batching mengurangi overhead per event, tapi menambah jeda.
• Koneksi tidak stabil membutuhkan retry dan buffer yang cukup agar tidak kehilangan data.

Sesuaikan properti produksi untuk jaringan WAN:

{
  "connect.timeout.ms": "30000",
  "connect.backoff.max.delay.ms": "120000",
  "connect.backoff.initial.delay.ms": "1000"
}

Ukur latency yang dapat diterima untuk use case kalian. Untuk sinkronisasi cache, latency beberapa detik masih wajar; untuk audit compliance real-time, topologi mungkin perlu didekatkan.

#Data Sovereignty dan Compliance Lintas Batas

Mengirim data melintasi region juga melintasi yurisdiksi. Data yang dikumpulkan di satu negara sering tidak boleh disimpan di negara lain. Strategi yang berlaku:

• Region pinning: pastikan data yang tunduk pada hukum tertentu tidak keluar dari regionnya.
• Filtering berbasis region: gunakan table.include.list atau SMT untuk menyaring data yang tidak boleh direplikasi.
• Masking lintas batas: masking kolom PII sebelum event meninggalkan region asal.

{
  "transforms": "maskRegion",
  "transforms.maskRegion.type": "org.apache.kafka.connect.transforms.MaskField$Value",
  "transforms.maskRegion.fields": "national_id",
  "transforms.maskRegion.replacement": "REDACTED"
}

Gunakan kolom national_id yang dimasking saat melewati batas region. Dokumentasikan keputusan ini dalam data contract agar tim lain tahu bahwa kolom tersebut sengaja tidak tersedia di region tujuan.

#Memantau Replikasi Lintas Region

Replikasi antar region membutuhkan observability yang lebih ketat karena kegagalan sering baru terasa setelah latency menumpuk. Metrik yang wajib dipantau:

• Latency end-to-end: dari database sumber sampai event tiba di Kafka tujuan.
• Backlog: jumlah event yang mengantre di region asal menunggu dikirim.
• Koneksi WAN: availability dan round-trip time jalur antar region.

Jika backlog terus membesar, kemungkinan besar bandwidth WAN menjadi bottleneck. Kurangi dengan memperbesar batch produksi atau memfilter event yang tidak penting untuk dikirim lintas region.

#Strategi Conflict Resolution

Saat dua region menulis ke tabel yang sama, replikasi dua arah menimbulkan potensi konflik. Strategi yang umum dipakai:

• Single writer per region: hanya satu region yang boleh menulis tabel tertentu.
• Last-write-wins: membandingkan source.ts_ms dan memakai nilai terbaru.
• Hindari two-way replication: arahkan replikasi satu arah dari region primer ke region lain.

Untuk kebanyakan kasus, memilih single writer per region jauh lebih aman daripada menyelesaikan konflik saat terjadi. Dokumentasikan aturan ini dengan jelas agar setiap tim tahu region mana yang berwenang menulis tabel mana.

Selain itu, selalu uji perilaku replikasi dua arah di lingkungan staging sebelum mengaktifkannya di produksi. Konflik yang tampak sederhana bisa menghasilkan divergensi data yang sulit dideteksi setelah berjalan berminggu-minggu.

#Penutup

Episode 14 memperluas jangkauan pipeline lintas wilayah: replikasi hub and spoke antar region, Debezium Server untuk jembatan on-premise ke cloud, tuning untuk jaringan WAN, dan kebijakan data sovereignty yang menjaga kepatuhan lintas batas.

Inti yang harus dibawa pulang:

• Gunakan topic.prefix unik per region dan replikasi async antar cluster Kafka.
• Debezium Server menghubungkan database on-premise ke cloud tanpa Kafka Connect penuh.
• Latency lintas region setidaknya sebesar latency jaringan; tuning batching dan backoff.
• Data sovereignty membutuhkan region pinning, filtering, dan masking.
• Dokumentasikan kebijakan lintas batas dalam data contract.

Di episode 15 selanjutnya kita akan membahas performance dan throughput — mengoptimalkan throughput connector dan kecepatan snapshot, parallelism dan konfigurasi task, tuning database sumber, dan meminimalkan dampak ke sistem OLTP.