Gambar 1. Alur checkout toko daring lewat antrean yang dibaca tiga konsumen, ilustrasi penulis (sumber: https://docs.redpanda.com/streaming/25.3/home.md)

Hai, Software Engineers! Bayangkan toko daring Anda menggelar obral tengah malam dan ribuan pembeli menekan tombol bayar dalam satu menit. Layanan pembayaran melambat, pencatatan stok ikut tersendat, tumpukan notifikasi menggunung, lalu permintaan mulai gagal satu per satu karena waktu tunggu habis. Pernahkah Anda melihat kegagalan berantai seperti ini pada aplikasi yang layanannya saling memanggil langsung? Pola panggilan langsung membuat satu layanan yang lambat menular ke seluruh sistem.

Panggilan Langsung dan Masalahnya

Pada arsitektur panggilan langsung, layanan checkout memanggil API pembayaran lalu menunggu jawaban sebelum mengurangi stok. Penantian ini menahan utas dan koneksi selama layanan lain bekerja, sehingga lonjakan pembeli cepat menghabiskan kapasitas server. Pembaruan satu layanan juga memaksa layanan tetangga menyesuaikan format JSON dan jadwal deploy yang sama. Dampaknya, tim bergerak lambat karena perubahan kecil butuh koordinasi banyak pihak.

Cara Kerja Antrean: Tulis Sekali, Dibaca Banyak Konsumen

Antrean event membalik pola komunikasi dari telepon menjadi papan pesan. Produsen menulis satu event ke topik lalu langsung melanjutkan kerja tanpa menunggu siapa pun. Broker menyimpan event itu di log terurut dan mereplikasinya ke banyak mesin agar tidak hilang oleh satu kegagalan. Gambar 1 memperlihatkan alur ini pada contoh checkout toko daring.

Dokumentasi Kafka membagi jaminan pengiriman pesan menjadi tiga, yaitu at-most-once yang boleh hilang, at-least-once yang boleh ganda, dan exactly-once yang tiba tepat satu kali. Pilihan at-least-once membuat sistem aman dari kehilangan data, tetapi pengiriman ulang membuka peluang duplikat saat respons konfirmasi hilang di jaringan. Sejak versi 0.11.0.0, produsen Kafka menyediakan opsi idempoten: broker memberi tiap produsen ID lalu membuang duplikat lewat nomor urut yang dikirim bersama tiap pesan. Gambar 2 membandingkan pengiriman ulang tanpa dan dengan mekanisme ini.

Gambar 2. Pengiriman ulang tanpa dan dengan idempotency, ilustrasi penulis(sumber: https://docs.confluent.io/kafka/design/delivery-semantics.html)

Contoh E-commerce: Satu Order Masuk, Tiga Kerja Jalan

Order bernomor order-123 ditulis sekali ke antrean, lalu tiga konsumen bekerja paralel tanpa saling menunggu. Konsumen pembayaran menagih kartu, konsumen stok mengurangi jumlah barang, dan konsumen notifikasi mengirim surel konfirmasi kepada pembeli. Setiap konsumen mencatat posisi bacanya sendiri, sehingga layanan yang mati sesaat tinggal melanjutkan dari posisi terakhir saat hidup kembali.

Masalah muncul ketika respons pembayaran hilang dan produsen mengirim ulang event yang sama. Broker idempoten mengenali nomor urut ganda lalu membuang salinannya sebelum masuk log, sehingga antrean tetap berisi satu event. Di sisi konsumen, kunci idempotency membuat pemrosesan ulang berhenti pada pengecekan status tanpa menagih kartu kedua kali, seperti pola yang dianjurkan panduan arsitektur event-driven AWS. Kombinasi dua lapis ini menjaga pelanggan membayar sekali walau jaringan sempat gagal.

Tim yang ingin mencoba pola ini tanpa mengelola klaster Kafka yang berat dapat memakai Redpanda sebagai platform yang kompatibel dengan Kafka. Redpanda menyatakan klien Kafka protokol versi 0.11 ke atas berjalan dengan sedikit atau tanpa perubahan pada aplikasi. Kompatibilitas ini membuat tim memindahkan beban kerja yang sudah memakai pustaka Kafka tanpa menulis ulang kode integrasi.

Perbedaan tiga semantik pengiriman terasa pada jaminan dan risikonya:

Aspek At-most-once At-least-once Exactly-once
Jaminan kirim Terkirim sekali, boleh hilang saat gagal Tiba minimal sekali, tidak hilang Tiba tepat satu kali
Risiko utama Data hilang tanpa sadar Pesan ganda saat retry Latensi dan kerumitan naik
Cocok untuk Metrik yang boleh bocor Order dan pembayaran dengan konsumen idempoten Aliran antar-topik yang butuh ketepatan penuh

Antrean Bukan Solusi Ajaib

Lapisan baru ini butuh pemantauan, sehingga tim kecil perlu menimbang manfaatnya sebelum adopsi. Urutan pesan, pesan ganda, dan konsumen yang lambat tetap meminta perhatian lewat desain yang cermat. Konsumen perlu idempoten karena jaminan at-least-once membuat duplikat mungkin tiba kapan saja. Dokumentasi SQS mengingatkan antrean standar boleh mengirim salinan pesan lebih dari sekali dan sesekali di luar urutan.

Pola ini cocok ketika beban kerja naik turun dan banyak layanan butuh data yang sama tanpa saling mengunci. Mulailah dari satu alur kecil seperti notifikasi, ukur throughput dan error selama sepekan, lalu perluas ke pembayaran setelah konsumen idempoten berjalan stabil. Aplikasi yang tadinya saling menelepon kini cukup menitip pesan di antrean, dan tiap layanan kembali fokus pada tugasnya. Arsitektur antrean kerja berbasis Kafka yang menjadi acuan pola ini tampak pada Gambar 3.

Gambar 3. Diagram arsitektur antrean kerja berbasis Kafka oleh Pchelolo, CC-BY-SA 4.0 (sumber: https://commons.wikimedia.org/wiki/File:Kafka_Job_Queue_Architecture_diagram.svg)

Referensi

  1. Confluent. Kafka Message Delivery Guarantees. https://docs.confluent.io/kafka/design/delivery-semantics.html
  2. Redpanda. Kafka Compatibility. https://docs.redpanda.com/streaming/current/develop/kafka-clients
  3. Redpanda. Redpanda Streaming Documentation. https://docs.redpanda.com/streaming/25.3/home.md
  4. AWS. Amazon SQS standard queues. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html
  5. AWS Samples. Idempotency | Event-driven Architecture on AWS. https://aws-samples.github.io/eda-on-aws/concepts/idempotency/