Replay Capability #
Dalam arsitektur event-driven modern, kemampuan untuk melakukan replay sering menjadi pembeda utama antara message broker tradisional dan distributed log system.
Replay berarti:
- Membaca ulang pesan yang sudah pernah diproses
- Mengulang proses historis
- Membangun ulang state dari event masa lalu
RabbitMQ dan Kafka memiliki pendekatan yang sangat berbeda terhadap replay capability.
Artikel ini membahas perbandingan keduanya secara mendalam.
“Sistem yang matang bukan hanya mampu memproses data hari ini — tetapi juga mampu kembali ke masa lalu ketika dibutuhkan.”
Apa Itu Replay Capability? #
Replay capability adalah kemampuan sistem untuk:
- Mengakses kembali message lama
- Memproses ulang message tersebut
- Tanpa harus mengirim ulang dari producer
Replay sangat penting dalam:
- Event sourcing
- Rebuild projection
- Debugging historis
- Data recovery
- Analytics ulang
Replay di RabbitMQ #
Model Destructive Read #
RabbitMQ menggunakan model queue tradisional.
Alur normalnya:
Producer → Queue → Consumer → Ack → Message dihapus
Setelah message di-ack:
- Message dihapus permanen dari queue
- Tidak tersedia lagi
Artinya:
RabbitMQ tidak memiliki replay capability bawaan.
Bagaimana Jika Ingin Replay di RabbitMQ? #
Beberapa pendekatan yang mungkin dilakukan:
1️⃣ Tidak Meng-Ack (Tidak Direkomendasikan) #
Message tetap berada di queue.
Namun:
- Menghambat sistem
- Tidak scalable
- Bukan solusi nyata
2️⃣ Simpan Message ke Storage Eksternal #
Producer atau consumer menyimpan event ke:
- Database
- Object storage
- Event store terpisah
Replay dilakukan dari sistem tersebut.
Ini menambah kompleksitas arsitektur.
3️⃣ Publish Ulang Secara Manual #
Message dari DLQ atau log disubmit ulang.
Namun ini bukan replay native.
RabbitMQ memang tidak dirancang untuk event history.
Replay di Kafka #
Kafka dirancang sebagai append-only log.
Message tidak dihapus setelah dibaca.
Consumer menyimpan:
- Offset
Artinya:
- Consumer bisa mengatur ulang offset
- Membaca ulang dari posisi sebelumnya
- Bahkan membaca dari awal log
Kafka memiliki replay capability secara native.
Bagaimana Kafka Mengaktifkan Replay? #
Setiap message di Kafka:
- Disimpan dalam log berdasarkan partition
- Memiliki offset unik
Consumer group menyimpan offset terakhir yang sudah diproses.
Untuk replay:
- Reset offset ke nilai sebelumnya
- Atau ke offset 0
- Atau berdasarkan timestamp tertentu
Log tetap tersedia selama retention belum habis.
Retention dan Replay #
Replay di Kafka bergantung pada retention policy:
- Time-based retention (misal 7 hari)
- Size-based retention
- Log compaction
Selama message masih berada dalam log, replay dimungkinkan.
Retention menentukan batas historis replay.
Perbandingan Replay Capability #
| Aspek | RabbitMQ | Kafka |
|---|---|---|
| Model dasar | Queue | Append-only log |
| Message dihapus setelah ack | Ya | Tidak |
| Offset tracking | Broker | Consumer |
| Replay native | Tidak | Ya |
| Cocok untuk event sourcing | Tidak ideal | Sangat cocok |
Kafka jelas unggul dalam replay capability.
Implikasi Arsitektural #
Jika sistem membutuhkan:
- Audit log lengkap
- Rebuild state dari awal
- Debugging historis
- Machine learning retraining
Kafka adalah pilihan alami.
Jika sistem hanya membutuhkan:
- Work distribution
- Task processing
- Low latency workflow
RabbitMQ sudah cukup dan lebih sederhana.
Replay dan Konsistensi #
Replay memungkinkan:
- Rekonstruksi state
- Validasi ulang logic bisnis
- Recovery dari bug lama
Namun juga memiliki konsekuensi:
- Event harus immutable
- Schema evolution harus backward compatible
- Consumer harus idempotent
Replay bukan sekadar fitur teknis. Ia adalah paradigma desain.
Misconception Umum #
“RabbitMQ bisa saja replay jika tidak di-ack.”
Itu bukan replay. Itu hanya menunda penghapusan.
Replay sejati berarti kemampuan membaca ulang event historis tanpa mengganggu sistem utama.
Itu bukan karakteristik queue tradisional.
Ringkasan #
RabbitMQ:
- Tidak memiliki replay native
- Cocok untuk delivery-oriented system
Kafka:
- Replay native melalui offset reset
- Cocok untuk event history dan streaming
Penutup #
Replay capability bukan hanya fitur tambahan.
Ia menentukan apakah sistem memandang pesan sebagai pekerjaan sementara — atau sebagai fakta historis.
RabbitMQ memandang pesan sebagai unit kerja yang harus diselesaikan. Kafka memandang pesan sebagai catatan yang harus disimpan.
Memahami perbedaan ini penting agar arsitektur tidak dibangun dengan asumsi yang salah.
Karena dalam sistem terdistribusi modern, kemampuan untuk kembali ke masa lalu sering kali sama pentingnya dengan kemampuan untuk memproses masa kini.