Belajar Redis - Streams (Event Streaming & Message Broker)

#Pendahuluan

Sejauh ini kalian sudah menguasai struktur data klasik Redis. Sekarang waktunya fitur yang mengubah Redis menjadi message broker dan event streaming platform: Redis Streams.

Streams adalah struktur log-based — data append-only yang diorganisir berdasarkan ID — dirancang untuk event streaming yang mirip Apache Kafka, tapi built-in di Redis tanpa infrastruktur tambahan. Di episode ini kita akan membedah penulisan dan pembacaan event, lalu masuk ke consumer groups untuk distributed message processing dengan jaminan delivery. Ini materi yang paling disukai backend engineer.

#Konsep Redis Streams

#Struktur Log Append-Only

Stream adalah deretan event yang hanya bisa ditambahkan di akhir (append-only). Tiap event punya ID unik berbasis timestamp (misal 1700000000000-0) dan satu atau lebih field-value pairs. Sifat append-only inilah yang membuat Streams cocok untuk event sourcing, audit log, dan data ingestion.

ID timestamp-seq → field-value
1650000000000-0 → event "order.created" payload "{...}"
1650000000001-0 → event "payment.received" payload "{...}"
1650000000002-0 → event "order.shipped" payload "{...}"

Karena data tersimpan dalam log, konsumen bisa membaca dari posisi mana pun — tidak seperti pub/sub yang fire-and-forget (episode 8).

#Berbeda dari List Queue

List (episode 4) adalah queue yang menghapus elemen saat di-pop — begitu dibaca, data hilang. Streams mempertahankan semua event dalam log, sehingga bisa dibaca ulang, dianalisis, dan diproses oleh banyak consumer group secara independen. Inilah perbedaan mendasar yang membuat Streams cocok untuk event-driven architecture.

#Operasi Dasar Streams

#Menulis dan Membaca Event

redis-cli XADD orders '*' event "order.created" orderId "123"
redis-cli XLEN orders

XADD orders '*' event "order.created" orderId "123" menambahkan event ke stream orders. Tanda * meminta Redis membuatkan ID otomatis dari timestamp. XLEN menghitung jumlah event.

Membaca event dengan rentang dan streaming:

redis-cli XRANGE orders - +
redis-cli XREAD COUNT 10 STREAMS orders 0

XRANGE orders - + membaca semua event (dari ID terkecil sampai terbesar). XREAD COUNT 10 STREAMS orders 0 membaca 10 event mulai dari ID 0. Untuk menunggu event baru, XREAD bisa memakai opsi BLOCK sehingga proses menanti dengan timeout — pola dasar konsumsi stream.

#Consumer Groups

#Konsep Distributed Processing

Saat satu stream dikonsumsi banyak worker, kita butuh pembagian kerja tanpa event terproses dua kali. Consumer groups menjawab ini: grup mencatat posisi konsumsi bersama, tiap event dikirim ke satu consumer saja, dan tiap consumer punya identitas sendiri.

redis-cli XGROUP CREATE orders order_group 0 MKSTREAM

XGROUP CREATE orders order_group 0 MKSTREAM membuat grup order_group pada stream orders. ID 0 berarti mulai dari awal; MKSTREAM membuat stream otomatis jika belum ada.

#Membaca dan Mengakui Pesan

redis-cli XREADGROUP GROUP order_group worker-1 COUNT 10 BLOCK 5000 STREAMS orders '>'

XREADGROUP GROUP order_group worker-1 COUNT 10 BLOCK 5000 STREAMS orders '>' membuat worker-1 membaca event yang belum dialokasikan ke siapa pun (>). Setelah diproses, worker wajib mengakui event:

redis-cli XACK orders order_group 1700000000000-0
redis-cli XPENDING orders order_group

XACK orders order_group 1700000000000-0 memberi tahu grup bahwa event ID tersebut sudah selesai diproses. XPENDING menampilkan daftar event yang belum di-ack — jika worker crash sebelum meng-ack, event akan tetap terlihat di sini.

#Recovery dengan XCLAIM

Saat sebuah worker crash di tengah pemrosesan, event-nya menggantung di pending list. Worker lain bisa mengklaim event tersebut setelah batas waktu tertentu:

redis-cli XCLAIM orders order_group worker-2 60000 1700000000000-0

XCLAIM orders order_group worker-2 60000 1700000000000-0 memindahkan ownership event ke worker-2, dengan syarat event sudah pending lebih dari 60.000 milidetik. Inilah mekanisme at-least-once delivery: event dijamin diproses minimal sekali, dan aplikasi harus siap menghadapi duplikat dengan idempotensi.

#Streams vs Apache Kafka vs Pub/Sub

#Posisi Streams di Ekosistem

Kafka unggul untuk throughput massive dan retention panjang dengan ekosistem lengkap (Kafka Connect, Schema Registry). Namun untuk skala menengah yang sudah memakai Redis, Streams menghilangkan kompleksitas mengoperasikan klaster Kafka. Pub/Sub di episode 8 tidak menyimpan apa pun — hanya broadcast — jadi Streams dan Pub/Sub saling melengkapi, bukan bersaing.

#Kapan Memakai Streams

Gunakan Streams saat: pesan harus bertahan walau tidak ada konsumen, perlu dibaca ulang, perlu consumer group dengan acknowledgment, atau butuh pemrosesan berurutan per key. Jika kebutuhan hanya notifikasi real-time sekali lewat, Pub/Sub lebih ringan.

#Use Case Umum

• Order processing: event order.created dikonsumsi worker untuk payment, inventory, dan notification.
• Event sourcing: simpan semua perubahan state sebagai urutan event yang bisa di-replay.
• Audit log: log append-only dengan ID timestamp terurut.
• IoT telemetry: pipeline data sensor yang diolah banyak consumer.
• Job queue yang reliable: pengganti List yang butuh acknowledgment.

#Penutup

Episode 6 membekali kalian Redis Streams sebagai event streaming dan message broker: XADD untuk menulis, XRANGE/XREAD untuk membaca, consumer groups dengan XREADGROUP untuk processing terdistribusi, serta XACK, XPENDING, dan XCLAIM untuk jaminan delivery dan recovery.

Inti yang harus dibawa pulang:

• Streams adalah log append-only dengan ID unik berbasis timestamp.
• XADD menulis, XRANGE/XREAD membaca, XLEN menghitung.
• Consumer groups membagi kerja antar worker tanpa event diproses dua kali.
• XACK wajib setelah event selesai diproses.
• XPENDING + XCLAIM memulihkan event dari worker yang crash.
• Delivery bersifat at-least-once — disain handler secara idempotent.
• Streams durable dan dapat di-replay, berbeda dengan Pub/Sub yang fire-and-forget.

Di episode 7 selanjutnya kita membahas Bitmaps, Bitfields & Geospatial Indexes — struktur untuk tracking dan pencarian berbasis lokasi. Bitmaps untuk Daily Active Users yang sangat hemat memori, Bitfields untuk penyimpanan integer compact, dan GEO commands untuk pencarian lokasi dalam radius. Lanjut!