Serialisasi, Schema Registry & Evolusi Skema — Belajar Apache Kafka

Masalah dengan JSON Polos

Kafka sendiri tidak peduli isi pesan — bagi broker, nilai pesan hanyalah deretan byte. Kebebasan ini nyaman di awal dan mahal kemudian.

🚫 Skema implisit adalah utang yang menagih di produksi

Produser mengganti nama field harga menjadi total_harga. Tiga konsumen rusak — dua di antaranya milik tim lain.
Tidak ada yang tahu bentuk pesan tanpa membaca kode produser atau menebak dari sampel.
JSON mengulang nama field di setiap pesan, memboroskan disk dan bandwidth.
Data lama di topik memakai bentuk lama, dan konsumen harus menebak versinya.

Schema Registry

Schema Registry menyimpan skema secara terpusat dan memberinya id. Pesan yang dikirim hanya membawa id skema, bukan seluruh definisinya.

Byte pesan (format wire Confluent):
  [ 0x00 ][ id skema 4 byte ][ payload biner ]
    ▲         ▲                  ▲
  magic    lookup ke registry   data terkompresi rapat

Konsumen mengambil skema berdasarkan id (dan menyimpannya di cache), lalu mendeserialisasi dengan benar — termasuk untuk pesan lama yang memakai skema versi sebelumnya.

Memilih Format

Format	Kelebihan	Pertimbangan
Avro	Ringkas, aturan evolusi paling matang, ekosistem data kuat	Pilihan default untuk pipeline analitik
Protobuf	Ringkas, cocok bila layanan sudah memakai gRPC	Berbagi definisi dengan API layanan
JSON Schema	Mudah dibaca manusia, mudah diadopsi	Boros ukuran; pakai bila keterbacaan lebih penting

Mode Kompatibilitas

Mode	Arti	Perubahan yang boleh
`BACKWARD`	Konsumen skema baru bisa membaca data lama	Hapus field; tambah field bernilai default
`FORWARD`	Konsumen skema lama bisa membaca data baru	Tambah field; hapus field bernilai default
`FULL`	Keduanya	Hanya tambah/hapus field bernilai default
`NONE`	Tanpa pemeriksaan	Semua — dan semua risikonya

⚠️ BACKWARD adalah default, dan default itu menentukan urutan rilis

Dengan BACKWARD, konsumen harus diperbarui lebih dulu, baru produser. Dengan FORWARD, urutannya terbalik. Tim yang tidak menyadari hal ini sering merilis produser lebih dulu lalu heran kenapa konsumen gagal mendeserialisasi.

🚫 Menambah field wajib tanpa nilai default

Ini pelanggaran kompatibilitas yang paling sering terjadi. Konsumen yang membaca pesan lama tidak menemukan field tersebut dan tidak punya nilai pengganti, sehingga deserialisasi gagal. Registry akan menolak pendaftaran skema semacam itu — dan penolakan tersebut adalah fitur, bukan penghalang yang perlu diakali dengan menyetel mode ke NONE.

Praktik yang Menghemat Banyak Waktu

Selalu beri nilai default pada field baru — ini membuat hampir semua penambahan aman.
Jangan pernah mendaur ulang nama field untuk arti yang berbeda; tambahkan field baru dan tandai yang lama sebagai usang.
Simpan definisi skema di repositori dan daftarkan lewat CI, bukan manual dari laptop.
Jalankan pemeriksaan kompatibilitas di CI agar perubahan yang merusak ditolak sebelum menyentuh produksi.
Sertakan metadata peristiwa — id peristiwa, waktu kejadian, versi produser — sejak hari pertama. Menambahkannya belakangan jauh lebih sulit.

💡 Nama topik dan strategi subject

Secara default registry memakai TopicNameStrategy: subject bernama namatopik-value. Bila satu topik memuat beberapa jenis peristiwa, gunakan RecordNameStrategy atau TopicRecordNameStrategy agar tiap jenis punya riwayat skema sendiri.