Belajar Apache Kafka - Message Ordering & Delivery Semantics

#Pendahuluan

Pertanyaan yang paling sering muncul di setiap tim yang mengadopsi Kafka: apakah urutan pesan dijamin? dan apakah pesan bisa hilang atau terkirim dua kali? Jawabannya tidak hitam-putih — keduanya bergantung pada keputusan desain topic, producer, dan consumer.

Episode 8 ini akan memisahkan mitos dari fakta: kalian akan memahami ordering yang dijamin Kafka (per partition dan per key), mengapa global ordering sangat mahal, serta tiga level delivery semantics — at-most-once, at-least-once, dan exactly-once (EOS). Di akhir, kita bedah implementasi EOS dengan idempotent producer dan transactional API yang akan diperdalam di episode 9.

Ini salah satu episode paling konseptual, jadi pahami perlahan. Keputusan semantics menentukan konsistensi seluruh sistem kalian.

#Ordering Guarantees

#Partition-Level Ordering

Kafka menjamin ordering di dalam satu partition: record ditulis sesuai urutan kedatangan dan dibaca dalam urutan yang sama. Ini adalah jaminan inti Kafka. Consumer dalam satu group yang membaca satu partition akan selalu melihat record dalam urutan yang sama dengan saat diproduksi.

Jaminan ini bergantung pada satu syarat: producer tidak boleh mengirim dua record ke partition yang sama secara bersamaan dengan reordering akibat retry. Inilah mengapa idempotent producer menetapkan max.in.flight.requests.per.connection=5 sambil tetap menjamin urutan — nomor sekuens di broker mendeteksi reorder.

#Key-Based Ordering

Karena key yang sama selalu menuju partition yang sama, semua record dengan key yang sama dijamin urutannya. Ini adalah cara paling umum menjaga ordering per entitas: key = order_id, user_id, atau device_id. Semua event untuk satu entitas akan diproses berurutan, sementara entitas berbeda bisa diproses paralel.

#Global Ordering dan Timestamp Ordering

Kafka tidak menjamin global ordering — record di partition berbeda tidak memiliki urutan keseluruhan. Mendapatkan global ordering berarti memaksa semua record masuk satu partition, yang mengorbankan semua paralelisme dan throughput. Praktiknya, konsisten per key sudah cukup untuk hampir semua kasus.

Ordering berdasarkan event time (timestamp di record) juga tidak dijamin oleh Kafka — urutan log adalah ingestion order. Untuk pemrosesan berbasis event time, gunakan windowing di Kafka Streams (episode 13).

#Delivery Semantics

#At-Most-Once

Pada at-most-once, record dikirim dan di-commit offset sebelum diproses. Jika pemrosesan gagal, record dilewati — data bisa hilang. Konfigurasi yang menghasilkan ini: acks=0 di producer, dan consumer commit offset sebelum proses. Cocok untuk metrik non-kritis di mana kehilangan data lebih dapat diterima daripada duplikasi.

#At-Least-Once

Pada at-least-once, record di-commit setelah diproses. Jika crash terjadi antara proses dan commit, record diproses ulang — tidak ada yang hilang, tetapi bisa duplikat. Konfigurasi: acks=all di producer, consumer commit setelah proses. Ini adalah level default yang dipakai hampir semua deployment, dan duplikat ditangani dengan consumer yang idempotent — memproses record yang sama menghasilkan efek yang sama.

#Exactly-Once Semantics (EOS)

Exactly-once berarti setiap record diproses tepat satu kali, tanpa kehilangan dan tanpa duplikasi — di mata sistem downstream. Ini adalah level yang paling sulit dan mahal. Kafka mencapai EOS melalui tiga mekanisme yang bekerja bersama:

1. Idempotent producer (enable.idempotence=true) mencegah duplikasi karena retry.
2. Transactional API membuat pengiriman lintas partition atomic.
3. Read-committed consumer (isolation.level=read_committed) hanya membaca record dari transaksi yang sudah commit.

# Producer
enable.idempotence=true
transactional.id=order-processor-1
 
# Consumer
isolation.level=read_committed

#Implementasi Exactly-Once

#Idempotent Producers sebagai Fondasi

Idempotence bekerja dengan memberi tiap producer sebuah producer ID (PID) dan nomor sekuens per partition. Broker menyimpan pasangan (PID, partition, sequence) untuk mendeteksi record duplikat dan menolak yang keluar urutan. Hasilnya: retry tidak pernah menghasilkan duplikat, dan record dari satu partition selalu masuk dalam urutan yang benar.

#Transactional API

Untuk membuat beberapa pengiriman atomic — misalnya menulis ke dua topic sekaligus — gunakan transactional API:

producer.initTransactions();
try {
    producer.beginTransaction();
    producer.send(new ProducerRecord<>("orders", "order-001"));
    producer.send(new ProducerRecord<>("order-events", "order-001"));
    producer.commitTransaction();
} catch (Exception e) {
    producer.abortTransaction();
}

Semua record dalam transaksi terlihat oleh consumer read_committed hanya ketika commitTransaction() berhasil. Jika gagal, abortTransaction() memastikan tidak ada yang terlihat.

#Transaction Coordinators dan Read Committed

Setiap transaksi dikelola oleh transaction coordinator — broker yang melacak status transaksi dan menyimpan hasilnya di topic internal __transaction_state. Consumer dengan isolation.level=read_committed menahan record dari transaksi yang belum commit dan membuang record dari transaksi yang di-abort; read_uncommitted melihat semua, termasuk yang belum commit.

#Use Case dan Trade-Offs EOS

Gunakan EOS untuk alur yang benar-benar membutuhkan atomicity dan zero-duplicate: stream processing end-to-end, pemindahan dana, atau sinkronisasi state kritis. Trade-off-nya nyata: throughput lebih rendah, latensi naik, dan kompleksitas operasional bertambah. Untuk sebagian besar pipeline, at-least-once dengan consumer idempotent sudah sangat memadai.

#Trade-Offs dan Pilihan

Ringkasan panduan memilih delivery semantics:

At-most-once : metrik boleh hilang, throughput puncak
At-least-once: default aman, atasi duplikat di consumer
Exactly-once : state kritis, siap bayar biaya throughput

Sebelum memilih EOS, tanyakan: apakah dampak duplikat benar-benar merugikan? Jika tidak, at-least-once jauh lebih murah untuk dioperasikan. Jika ya, pastikan seluruh pipeline memakai fitur transaksional Kafka agar janjinya terpenuhi.

#Penutup

Di episode 8 ini kalian sudah memahami jaminan ordering Kafka: per partition dan per key, dengan global ordering yang tidak dijamin. Kalian juga memahami tiga delivery semantics — at-most-once, at-least-once, dan exactly-once — beserta mekanisme EOS: idempotent producer, transactional API, dan read-committed consumer.

Inti yang harus dibawa pulang:

• Ordering dijamin per partition; key yang sama dijamin urutannya.
• Global ordering tidak dijamin dan sangat mahal.
• At-least-once dengan consumer idempotent adalah default produksi yang umum.
• EOS butuh idempotent producer, transaction, dan read_committed secara bersama.
• Transaction coordinator melacak status transaksi di topic internal.
• EOS end-to-end hanya berlaku jika seluruh pipeline memakai Kafka.

Di episode 9 selanjutnya kita akan mengerjakan Kafka transactions secara praktik: lifecycle initTransactions, beginTransaction, send, commitTransaction, dan abortTransaction, pola read-process-write, konfigurasi transactional.id dan transaction.timeout.ms, serta pengaruhnya terhadap throughput dan latensi. Siapkan cluster kalian untuk uji coba transaksi nyata!