Hana — VyuApp Support
Online
20/20 pesan tersisa
🌸 Selamat datang di VyuApp! Saya Hana, ada yang bisa saya bantu hari ini?
Semua artikel

Engineering

Redis Streams: Panduan Lengkap untuk Developer Indonesia

Pelajari Redis Streams dari dasar hingga implementasi: commands, consumer groups, use cases, perbandingan dengan Kafka, dan best practices untuk production.

4 Juli 2026 9 min read#Redis#Redis Streams#Message Queue#Event Streaming
Redis Streams: Panduan Lengkap untuk Developer Indonesia

Redis Streams adalah tipe data yang diperkenalkan di Redis 5.0 untuk menangani aliran data secara real-time. Artikel ini membahas konsep dasar, commands utama, consumer groups, perbandingan dengan Kafka, dan cara implementasinya.

Apa Itu Redis Streams?

Macbook screen shows macos software update downloading

Redis Streams menyimpan data dalam struktur append-only log di memory

Redis Streams adalah struktur data append-only log yang ada di Redis sejak versi 5.0 (Oktober 2018). Setiap data baru selalu ditambahkan di akhir stream, mirip seperti menulis log file yang terus bertambah. Bedanya, data ini ada di memory sehingga aksesnya sangat cepat.

Setiap entry dalam stream punya ID unik dengan format <timestamp>-<sequence>, misalnya 1678456789123-0. ID ini di-generate otomatis berdasarkan waktu milidetik dan nomor urut. Di dalamnya berisi satu atau lebih pasangan field-value, mirip seperti hash di Redis.

Kenapa Streams penting? Karena Redis Pub/Sub yang ada sebelumnya punya kelemahan besar: pesan yang tidak tertangkap subscriber hilang selamanya. Streams memperbaiki ini dengan menyimpan semua pesan sehingga bisa di-replay kapan saja.

Catatan: Redis Streams bukan replacement untuk Kafka. Streams cocok untuk use case yang butuh latency rendah dan throughput tinggi dengan kompleksitas lebih rendah. Kalau butuh long-term retention data terabytes, tetap pakai Kafka.

Commands Utama yang Harus Dikuasai

Ada sekitar 12 commands utama untuk Redis Streams. Saya akan fokus ke yang paling sering dipakai.

XADD - Menambah Data ke Stream

XADD adalah command pertama yang dipelajari. Fungsinya menambahkan entry baru ke stream. Kalau stream belum ada, Redis akan membuatnya otomatis.

# Tambah entry ke stream "orders"
XADD orders * product "Laptop" amount "15000000" status "pending"
# Output: "1678456789123-0"

# Tambah dengan ID manual
XADD orders 1678456789123-1 product "Mouse" amount "150000"

Tanda bintang (*) di parameter ID meminta Redis untuk generate ID otomatis. Ini yang paling sering dipakai karena lebih praktis.

XREAD dan XREADGROUP - Membaca Data

XREAD membaca entry dari satu atau lebih stream. Bisa dipakai dalam mode blocking dengan parameter BLOCK sehingga consumer menunggu sampai ada data baru masuk.

# Baca 10 entry terbaru dari stream "orders"
XREAD COUNT 10 STREAMS orders $

# Baca dengan blocking (tunggu max 5 detik)
XREAD COUNT 1 BLOCK 5000 STREAMS orders $

XREADGROUP adalah versi yang lebih canggih untuk dipakai bersama consumer groups. Setiap consumer dalam group mendapat entry yang berbeda, jadi tidak ada duplikasi.

# Baca sebagai bagian dari consumer group
XREADGROUP GROUP order_processors worker1 COUNT 5 STREAMS orders >

Tanda > artinya ambil entry yang belum pernah dikirim ke consumer group ini.

XACK dan XCLAIM - Acknowledgment

Setelah consumer memproses entry, ia harus mengirim XACK untuk menandai bahwa entry sudah selesai diproses. Entry yang tidak di-ACK akan masuk pending list dan bisa di-claim oleh consumer lain jika yang pertama mati atau crash.

# Tandai entry sebagai sudah diproses
XACK orders order_processors 1678456789123-0

# Ambil alih entry dari consumer lain yang mati (idle 60 detik)
XCLAIM orders order_processors worker2 60000 1678456789123-0

Consumer Groups: Fitur Paling Powerful

Cable network

Consumer groups memungkinkan beberapa worker memproses data secara paralel

Consumer groups adalah alasan utama kenapa Redis Streams jauh lebih berguna daripada Pub/Sub. Dengan consumer group, beberapa client bisa bekerja sama mengkonsumsi data dari stream yang sama tanpa duplikasi.

Cara kerjanya:

  1. Buat consumer group dengan XGROUP CREATE
  2. Consumer membaca entry dengan XREADGROUP
  3. Consumer memproses entry yang diterima
  4. Consumer mengirim XACK setelah selesai
  5. Kalau consumer crash sebelum ACK, entry bisa di-claim consumer lain dengan XCLAIM

Redis secara otomatis melacak entry yang sudah dikirim tapi belum di-ACK lewat mekanisme yang disebut Pending Entries List (PEL). Ini yang memungkinkan fault tolerance.

Pattern Fan-Out: Consumer groups berbeda bisa membaca dari stream yang sama secara independen. Misalnya, stream "orders" dibaca oleh group "payment_processor" dan "notification_sender" secara paralel. Setiap group mendapat copy entry-nya sendiri.

Manfaat consumer groups untuk distributed processing:

  • Load balancing otomatis antar consumers
  • Fault tolerance lewat pending entries list
  • Horizontal scaling dengan menambah consumers baru
  • Guaranteed at-least-once delivery

Kapan Harus Pakai Redis Streams?

Ada beberapa use case di mana Redis Streams benar-benar bersinar:

IoT Data Ingestion

Sensor dari ribuan perangkat mengirim data ke stream setiap detik. Multiple workers mengambil data dari consumer group untuk diproses secara paralel untuk alerting, storage, dan analytics.

Message Queue yang Lebih Baik

Redis Streams bisa menggantikan Redis List sebagai message queue. Kelebihannya: persistence, consumer groups, dan acknowledgment. Cocok untuk task queue di mana setiap task harus diproses tepat sekali.

Event Sourcing

Setiap perubahan state di-append ke stream sebagai event. State bisa di-replay dari history events. Berguna untuk sistem audit atau banking di mana setiap transaksi harus tercatat.

Real-Time Analytics

Kumpulkan event dari aplikasi (page views, clicks, purchases) ke stream, lalu proses secara real-time untuk dashboard dan metrics.

// Advertisement

Log Aggregation

Microservices mengirim log ke stream terpusat. Log processor mengambil dari consumer group, parse, dan simpan ke Elasticsearch atau storage lain.

Redis Streams vs Alternatif Lain

Pertanyaan yang sering muncul: kapan pakai Redis Streams, kapan pakai Kafka atau RabbitMQ?

Aspek Redis Streams Apache Kafka RabbitMQ
Tipe In-memory data structure Distributed log system Message broker
Throughput 100K-1M+ msg/s Jutaan msg/s 20K-50K msg/s
Latency Sub-millisecond Low (ms range) Low-medium
Persistence Opsional Default Default
Consumer Groups Built-in Native Via competing consumers
Message Replay Ya Ya Tidak
Kompleksitas Rendah Tinggi Sedang
Best For Lightweight streaming Big data event streaming Traditional message routing

Kapan Memilih Redis Streams?

  • Sudah pakai Redis di stack, ingin tambah messaging tanpa dependency baru
  • Butuh latency sub-millisecond
  • Data volume moderat (tidak perlu petabyte-scale)
  • Ingin kombinasi caching + streaming dalam satu sistem
  • Tim kecil, ingin hindari kompleksitas Kafka

Kapan Harus Pilih Alternatif?

  • Butuh long-term retention (hari/minggu/bulan) pakai Kafka
  • Butuh complex routing (topic exchange, headers exchange) pakai RabbitMQ
  • Hanya butuh ephemeral pub/sub tanpa persistence pakai Redis Pub/Sub biasa
Baca juga: Pelajari lebih lanjut tentang Redis caching patterns untuk memahami bagaimana Redis bisa dipakai tidak hanya untuk streaming tapi juga untuk caching.

Contoh Implementasi

Berikut contoh sederhana producer-consumer menggunakan Python dengan library redis-py:

Producer: Mengirim Event ke Stream

import redis

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

# Tambah event ke stream
def produce_event(stream_name, data):
    entry_id = r.xadd(stream_name, data)
    print(f'Event ditambahkan: {entry_id}')
    return entry_id

# Kirim beberapa order
for i in range(10):
    produce_event('order_events', {
        'order_id': f'ORD-{1000+i}',
        'product': 'Laptop Asus',
        'amount': '15000000',
        'status': 'pending'
    })

print(f'Total entries: {r.xlen("order_events")}')

Consumer: Memproses Event dari Consumer Group

import redis

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

# Buat consumer group
try:
    r.xgroup_create('order_events', 'order_processors', id='0', mkstream=True)
except redis.exceptions.ResponseError:
    pass  # Group sudah ada

# Consumer loop
while True:
    messages = r.xreadgroup(
        groupname='order_processors',
        consumername='worker-1',
        streams={'order_events': '>'},
        count=1,
        block=5000  # Tunggu max 5 detik
    )

    if not messages:
        continue

    for stream, entries in messages:
        for entry_id, data in entries:
            print(f'Memproses: {data}')
            # Proses order di sini...

            # ACK setelah berhasil
            r.xack('order_events', 'order_processors', entry_id)
Penting: Selalu panggil XACK setelah memproses entry. Kalau tidak, entry akan masuk pending list dan consumer lain bisa mengambil alih, menyebabkan duplikasi pemrosesan.

Best Practices untuk Production

Beberapa hal yang perlu diperhatikan saat memakai Redis Streams di production:

1. Selalu Gunakan Consumer Groups

Jangan pakai XREAD biasa untuk production. Consumer groups memberikan load balancing, acknowledgment, dan fault tolerance yang sangat penting.

2. Setel MAXLEN untuk Trimming

Stream bisa tumbuh tak terbatas kalau tidak di-trim. Gunakan XTRIM atau parameter MAXLEN saat XADD:

# Batasi stream max 100.000 entry
XADD orders MAXLEN ~ 100000 * product "Laptop"

# Atau trim manual
XTRIM orders MAXLEN ~ 100000

Tanda ~ membuat trimming lebih efisien karena Redis tidak perlu memotong persis di angka tersebut.

3. Implementasikan Idempotency

Karena Redis Streams menjamin at-least-once delivery (bukan exactly-once), consumer mungkin menerima entry yang sama. Pastikan proses Anda idempotent.

4. Monitor dengan XPENDING

Secara rutin cek pending entries untuk mendeteksi entry yang stuck:

# Lihat 10 entry pending pertama
XPENDING order_events order_processors - + 10

# Lihat pending untuk consumer tertentu
XPENDING order_events order_processors - + 10 worker-1

// Advertisement

5. Gunakan XCLAIM untuk Recovery

Kalau consumer mati, entry-nya akan stuck di pending list. Implementasikan mekanisme XCLAIM untuk mengambil alih entry yang idle terlalu lama.

6. Aktifkan AOF Persistence

Secara default, data di Redis hanya ada di memory. Aktifkan AOF (Append-Only File) dengan appendfsync everysec untuk balance antara durability dan performa.

7. Pisahkan Stream per Domain

Gunakan naming convention yang jelas: orders:created, users:activity, payments:processed. Ini memudahkan routing dan monitoring.

Baca juga: Untuk memahami bagaimana caching dan streaming bekerja bersama dalam arsitektur modern, baca artikel tentang membangun data pipeline.

Pertanyaan yang Sering Diajukan

Apakah Redis Streams cocok untuk menggantikan Kafka?

Tergantung kebutuhan. Kalau butuh latency rendah dan volume data moderat, Redis Streams cukup. Tapi kalau butuh long-term retention terabytes atau exactly-once semantics, tetap pakai Kafka. Redis Streams lebih cocok sebagai "Kafka lite" untuk use case yang lebih sederhana.

Berapa banyak data yang bisa ditampung Redis Streams?

Tergantung RAM server. Karena data disimpan di memory, ukuran stream dibatasi oleh memori yang tersedia. Untuk stream besar, gunakan trimming dengan MAXLEN atau MINID untuk membatasi ukuran.

Bagaimana cara menangani consumer yang mati?

Gunakan kombinasi XPENDING untuk memantau entry stuck dan XCLAIM untuk mengambil alih entry dari consumer yang sudah tidak aktif. Setel timeout yang wajar (misal 60 detik) sebelum entry di-claim oleh consumer lain.

Apakah Redis Streams mendukung exactly-once delivery?

Tidak. Redis Streams menjamin at-least-once delivery. Consumer harus mengimplementasikan idempotency sendiri untuk memastikan entry tidak diproses dua kali. Ini bisa dilakukan dengan menyimpan ID entry yang sudah diproses.

Bisakah Redis Streams dipakai untuk event sourcing?

Bisa, dengan catatan. Redis Streams bagus untuk event sourcing jangka pendek karena sifatnya yang append-only. Tapi untuk long-term event store, pertimbangkan Kafka atau database event sourcing khusus karena keterbatasan memori Redis.

Kesimpulan

Redis Streams menawarkan cara yang ringan dan cepat untuk menangani data streaming tanpa perlu setup infrastruktur yang rumit. Dengan consumer groups yang built-in, persistence yang opsional, dan latency sub-millisecond, ini adalah pilihan yang tepat untuk banyak use case di mana Kafka terlalu berat.

Kuncinya: mulai sederhana dengan satu stream dan satu consumer group. Monitor performa dengan XPENDING dan XINFO. Scale dengan menambah consumers. Dan ingat untuk selalu setel trimming agar stream tidak memakan semua memory.

Butuh Bantuan Implementasi?

VyuApp membantu developer membangun sistem streaming yang efisien dan scalable. Kami berpengalaman dengan Redis, Kafka, dan berbagai message queue lainnya.

Konsultasi Gratis →

Sumber Referensi

  1. Redis Streams Official Documentation - Redis.io
  2. Redis Stream Consumers Documentation - Redis.io
  3. Redis Streams: A Comprehensive Guide - DEV Community
  4. Redis Streams Best Practices - DragonflyDB
  5. Event-Driven Architecture with Redis Streams - Harness.io

Image Attribution

  • Photo by Herry Sucahya on Unsplash - Unsplash
  • Photo by Taylor Vick on Unsplash - Unsplash
  • Photo by Samuel Angor on Unsplash - Unsplash
  • Photo by Deng Xiang on Unsplash - Unsplash
  • Photo by Duy Pham on Unsplash - Unsplash
  • Photo by TruckRun on Unsplash - Unsplash

// Advertisement

V

VyuApp Studio

Bespoke web engineering — Garut, ID