Belajar Debezium - Schema Registry & Data Contracts

#Pendahuluan

Saat data mengalir antar tim, struktur event adalah perjanjian tak tertulis yang paling sering dilanggar. Satu tim menambah kolom, tim lain pusing. Episode 9 ini membahas bagaimana schema registry mengubah perjanjian itu menjadi kontrak yang bisa ditegakkan, lengkap dengan versioning, aturan kompatibilitas, dan validasi otomatis.

Di episode 5 kalian sudah melihat peran schema registry dalam format payload. Sekarang kita naik satu tingkat: bukan sekadar menyimpan skema, tapi membangun data contract — kesepakatan eksplisit tentang bentuk dan makna setiap event yang dikonsumsi banyak pihak.

#Membangun Data Contract untuk Event Schema

Data contract menjawab tiga pertanyaan: struktur event seperti apa, siapa yang bertanggung jawab, dan bagaimana event boleh berevolusi. Dalam praktik Debezium, kontrak ini diwujudkan sebagai skema Avro atau Protobuf yang terdaftar di schema registry.

Mulai dengan menyalakan schema registry di compose stack:

  schema-registry:
    image: confluentinc/cp-schema-registry:7.8.0
    ports:
      - "8081:8081"
    environment:
      SCHEMA_REGISTRY_HOST_NAME: schema-registry
      SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: kafka:9092
      SCHEMA_REGISTRY_LISTENERS: http://0.0.0.0:8081

Setelah worker memakai AvroConverter dan menunjuk ke schema.registry.url, setiap event Debezium otomatis mendaftarkan skema saat connector pertama berjalan.

#Mengelola Versioning dan Compatibility Rules

Schema registry menyimpan riwayat setiap skema per subject. Subject Debezium biasanya dinamai topic.prefix.database.table-key atau -value:

curl -s http://localhost:8081/subjects | jq
curl -s http://localhost:8081/subjects/dbserver1.inventory.customers-value/versions | jq

Aturan compatibility menentukan seberapa bebas skema bisa berevolusi:

Setel kompatibilitas per subject dengan:

curl -s -X PUT http://localhost:8081/config/dbserver1.inventory.customers-value \
  -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  -d '{"compatibility": "BACKWARD"}'

Dengan BACKWARD, menambah kolom wajib memberi default — ini memaksa tim berpikir dua kali sebelum mengubah event yang sudah dipakai banyak konsumen.

#Menangani Schema Evolution pada Payload Debezium

Perubahan tabel database diterjemahkan Debezium menjadi versi skema baru. Skenario umum:

• Menambah kolom dengan default: kompatibel backward, konsumen lama tetap membaca.
• Menghapus kolom: hanya aman dengan kompatibilitas forward atau jika tidak ada konsumen yang membutuhkannya.
• Mengubah tipe data: hampir selalu melanggar kompatibilitas, perlu strategi migrasi khusus.

Debezium menghasilkan skema value yang menyatu dari semua kolom tabel. Karena itu sebelum mengubah skema tabel di produksi, cek dulu kompatibilitasnya dengan subject terkait:

curl -s -X POST http://localhost:8081/compatibility/subjects/dbserver1.inventory.customers-value/versions/latest \
  -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  -d '{"schema": "{...skema baru...}"}'

#Menggunakan Avro dan Protobuf untuk Validasi Konsumen

Validasi di sisi konsumen adalah lapisan terakhir dari data contract. Konsumen Avro memuat skema dari registry, sementara Protobuf memakai file .proto yang di-generate. Keduanya memberi keuntungan:

• Deserialisasi aman: event yang tidak sesuai skema langsung ditolak.
• Evolusi terkontrol: perubahan skema disetujui registry sebelum masuk produksi.
• Dokumentasi hidup: skema itu sendiri adalah dokumentasi struktur data.

#Subject untuk Key dan Value

Debezium mendaftarkan dua subject untuk setiap topic: satu untuk key dan satu untuk value. Subject key biasanya berisi skema primary key — misalnya dbserver1.inventory.customers-key — sedangkan subject value berisi skema seluruh kolom tabel. Pemisahan ini penting karena key dan value sering berevolusi pada kecepatan yang berbeda.

Saat menambahkan kolom baru pada tabel, hanya subject value yang berubah. Konsumen yang hanya bergantung pada key tetap bisa membaca tanpa masalah selama subject key tidak disentuh.

#Strategi Kompatibilitas untuk Debezium

Karena Debezium menghasilkan skema dari tabel database, pilih level kompatibilitas yang selaras dengan cara tabel berubah:

• Gunakan BACKWARD bila penambahan kolom sering terjadi dan harus diberi default.
• Gunakan FULL bila kalian tidak ingin khawatir dengan arah evolusi.
• Hindari NONE pada subject produksi kecuali benar-benar paham risikonya.

Perlu diingat bahwa Debezium mengirim skema lengkap untuk setiap event pada mode JSON, tetapi dengan Avro atau Protobuf, skema dikirim sekali dan event hanya membawa ID skema. Perbedaan inilah yang membuat mode Avro jauh lebih hemat bandwidth di topic dengan lalu lintas tinggi.

#Penutup

Episode 9 mengubah skema event dari catatan kaki menjadi kontrak: schema registry menyimpan versioning, aturan kompatibilitas menegakkan evolusi yang aman, dan Avro atau Protobuf memvalidasi event di sisi konsumen.

Inti yang harus dibawa pulang:

• Data contract mewujud sebagai skema yang terdaftar di schema registry.
• Subject mengikuti pola topic-key dan topic-value dengan riwayat versi.
• Level kompatibilitas BACKWARD, FORWARD, dan FULL mengendalikan evolusi skema.
• Perubahan tabel harus dicek kompatibilitasnya sebelum di-deploy ke produksi.
• Avro dan Protobuf memberi validasi otomatis di sisi konsumen.

Di episode 10 selanjutnya kita akan membahas security dan data privacy — mengamankan koneksi database dengan TLS, autentikasi dan service account, enkripsi payload di Kafka, serta kepatuhan GDPR dan data masking.