1. Titik Awal Masalah: Mengapa Arsitektur Lama Sering Ambruk di Produksi

Ingatkah Anda malam ketika sistem checkout e-commerce mendadak tumbang tepat saat kampanye diskon besar dimulai? Di layar monitor, metrik Grafana melompat merah menyala. CPU server backend Go melambung ke 95%, sementara koneksi database MySQL mencatat deadlock bertubi-tubi karena ribuan worker berebut memperbarui status pesanan secara bersamaan.

Masalah klasik ini biasanya berakar dari penggunaan arsitektur lama seperti Redis Pub/Sub murni atau antrean berbasis database relasional yang dipaksa bekerja di luar kodratnya. Redis Pub/Sub ibarat pengeras suara di tengah lapangan: pesan diteriakkan, dan jika ada worker yang sedang offline atau lambat, pesan tersebut lenyap begitu saja ke udara tanpa jejak. Tidak ada persistence, tidak ada acknowledgement, dan tentu saja tidak ada jaminan pengiriman. Ketika trafik melonjak, sistem menjadi rapuh bagai istana kartu.

[!WARNING] Jangan pernah menggunakan Redis Pub/Sub untuk job queue atau event processing yang kritikal. Kehilangan satu event pembayaran sama artinya dengan kehilangan kepercayaan pengguna dan potensi kerugian finansial.

Di sinilah kita membutuhkan pendekatan yang lebih matang, sebuah sistem yang mampu menjembatani kecepatan memori kilat Redis dengan ketahanan data yang dapat diandalkan. Mari kita telusuri bagaimana teknologi ini bekerja tanpa sihir, melainkan murni rekayasa sistem yang kokoh.

2. Di Balik Layar: Bagaimana Sistem Ini Bekerja Tanpa Sihir

Untuk memahami mengapa Redis Streams menjadi penyelamat dalam skenario tadi, mari kita bayangkan sebuah ban berjalan (conveyor belt) di pabrik modern. Setiap kali ada event baru—misalnya pengguna mendaftarkan akun atau melakukan klik tombol beli—sebuah item diletakkan di atas ban berjalan tersebut.

Berbeda dengan Pub/Sub yang langsung membuang pesan jika tidak ada penerima, Redis Streams mencatat setiap event secara sekuensial di dalam memori dengan ID unik berbasis timestamp (contoh: 1689000000000-0). Setiap event memiliki log abadi yang tersimpan rapi hingga batas kebijakan retensi tercapai. Ini memberi kita at-least-once delivery yang sangat didambakan oleh arsitek backend.

Lebih dari itu, konsep Consumer Groups bekerja layaknya tim supervisor di pabrik. Alih-alih semua worker memproses seluruh event yang sama (yang berakibat duplikasi pekerjaan), sebuah Consumer Group mendistribusikan beban secara cerdas. Worker A, Worker B, dan Worker C bekerja sama dalam satu grup; ketika sebuah event masuk, ia hanya dikirim ke salah satu worker. Jika worker tersebut mendadak crash sebelum menyelesaikan tugasnya, event tersebut tidak hilang, melainkan masuk ke dalam Pending Entries List (PEL) yang nantinya bisa diambil kembali lewat mekanisme claim.

Transisi dari kekacauan Pub/Sub menuju keteraturan Streams menuntut kita untuk memilih kompromi arsitektur yang tepat, yang akan kita bedah pada bagian berikutnya.

3. Pilihan Pendekatan & Kompromi yang Harus Diambil

Sebelum mengetikkan baris kode Go pertama, kita harus jujur pada diri sendiri mengenai kompromi infrastruktur. Tidak ada arsitektur perak yang bisa menyelesaikan segalanya tanpa konsekuensi.

Dalam membangun event-driven pipeline, kita dihadapkan pada tiga opsi utama:

Memilih Redis Streams berarti kita berkomitmen untuk memantau penggunaan memori RAM Redis dengan ketat. Karena data disimpan di dalam memori sebelum di-flush ke disk (jika menggunakan AOF/RDB), kapasitas server harus direncanakan secara matang. Dengan fondasi keputusan yang jelas ini, mari kita siapkan lingkungan kerja kita.

4. Meracik Lingkungan: Persiapan & Prasyarat Lapangan

Sebelum kita masuk ke ranah kode Go yang elegan, pastikan fondasi infrastruktur di mesin lokal atau server staging Anda sudah siap. Kita memerlukan Go (versi 1.20+) dan Redis Server (versi 5.0 ke atas, karena Redis Streams baru diperkenalkan di versi ini).

Mari kita buat direktori proyek baru daninisiasi modul Go:

mkdir -p redis-stream-pipeline
cd redis-stream-pipeline
go mod init github.com/username/redis-stream-pipeline

Selanjutnya, kita instal pustaka klien Redis paling populer dan matang untuk bahasa Go, yaitu go-redis:

go get github.com/redis/go-redis/v9

Untuk memastikan Redis berjalan dengan baik di lingkungan pengembangan, Anda bisa menjalankan kontainer Docker secara cepat:

docker run --name redis-stream-dev -p 6379:6379 -d redis:7-alpine

[!TIP] Selalu gunakan koneksi pooling yang optimal di go-redis saat menangani trafik tinggi di produksi. Atur PoolSize setidaknya dua kali lipat dari jumlah maksimum goroutine yang akan aktif secara bersamaan.

Dengan lingkungan yang sudah siap bersarang di mesin kita, saatnya meracik kode implementasi yang tangguh.

5. Langkah Implementasi: Membangun Solusi yang Tangguh

Sekarang kita akan menulis kode inti yang bertindak sebagai produsen (producer) event dan konsumen (consumer) berbasis Consumer Groups menggunakan Go.

Buat file bernama main.go dan masukkan struktur kode berikut:

package main

import (
	"context"
	"fmt"
	"log"
	"time"

	"github.com/redis/go-redis/v9"
)

const (
	streamKey = "order_events"
	groupName  = "order_processing_group"
	consumer   = "worker_1"
)

func main() {
	ctx := context.Background()
	rdb := redis.NewClient(&redis.Options{
		Addr:     "localhost:6379",
		Password: "", // kosongkan jika tidak ada password
		DB:       0,
	})

	// Pastikan koneksi Redis sehat
	if err := rdb.Ping(ctx).Err(); err != nil {
		log.Fatalf("Gagal terhubung ke Redis: %v", err.Error())
	}

	// Inisialisasi Consumer Group (abaikan error jika grup sudah ada)
	err := rdb.XGroupCreateMkStream(ctx, streamKey, groupName, "$").Err()
	TentukanErrorGrup(err)

	// Jalankan Producer secara asynchronous untuk simulasi
	go startProducer(ctx, rdb)

	// Jalankan Consumer
	startConsumer(ctx, rdb)
}

TentukanErrorGrup := func(err error) {
	if err != nil && err.Error() != "BUSYGROUP Consumer Group name already exists" {
		log.Fatalf("Gagal membuat consumer group: %v", err)
	}
}

func startProducer(ctx context.Context, rdb *redis.Client) {
	counter := 1
	for {
		values := map[string]interface{}{
			"order_id": fmt.Sprintf("ORD-%d", counter),
			"amount":   counter * 15000,
		}

		_, err := rdb.XAdd(ctx, &redis.XAddArgs{
			Stream: streamKey,
			Values: values,
		}).Result()

		if err != nil {
			log.Printf("[Producer Error] Gagal mengirim event: %v", err)
		} else {
			log.Printf("[Producer] Berhasil mengirim Order: ORD-%d", counter)
		}

		counter++
		time.Sleep(1 * time.Second)
	}
}

func startConsumer(ctx context.Context, rdb *redis.Client) {
	log.Printf("[Consumer] %s mulai mendengarkan event...", consumer)
	for {
		streams, err := rdb.XReadGroup(ctx, &redis.XReadGroupArgs{
			Group:    groupName,
			Consumer: consumer,
			Streams:  []string{streamKey, ">"},
			Count:    1,
			Block:    2 * time.Second,
		}).Result()

		If err != nil {
			continue
		}

		for _, stream := range streams {
			for _, message := range stream.Messages {
				// Proses event bisnis di sini
				log.Printf("[Consumer] Memproses Event ID: %s | Data: %v", message.ID, message.Values)

				// Kirim Acknowledgement (ACK) tanda selesai diproses
				err := rdb.XAck(ctx, streamKey, groupName, message.ID).Err()
				if err != nil {
					log.Printf("[Consumer Error] Gagal ACK pesan %s: %v", message.ID, err)
				}
			}
		}
	}
}

Kode di atas sudah memperlihatkan kerangka dasar yang solid. Namun, mari kita bedah beberapa baris kode krusial yang sering kali menjebak para engineer pemula di lapangan.

6. Membedah Baris Kode Krusial yang Kerap Menjebak

Perhatikan penggunaan tanda ">" pada argumen Streams: []string{streamKey, ">"} di dalam fungsi XReadGroup. Ini adalah salah satu fitur paling esensial sekaligus paling sering salah dipahami.

Simbol ">" menginstruksikan Redis untuk memberikan pesan baru yang belum pernah dikirimkan ke consumer lain di dalam Consumer Group yang sama. Jika Anda menggantinya dengan simbol "0", Anda justru menyuruh Redis membaca ulang seluruh Pending Entries List (PEL) milik consumer tersebut, yang bisa berakibat pembacaan pesan lama secara berulang-ulang jika tidak di-ACK dengan benar.

[!IMPORTANT] Jangan pernah lupa memanggil XAck setelah sebuah event berhasil diproses oleh worker. Jika XAck terlewat, pesan tersebut akan terus menumpuk di dalam Pending Entries List dan memakan memori Redis secara perlahan hingga menyebabkan kebocoran memori (memory leak) terselubung.

Selain masalah ACK, tantangan sesungguhnya datang ketika sistem mulai diguyur trafik tinggi dari berbagai penjuru web server.

7. Bertahan di Bawah Tekanan: Skenario Traffic Nyata

Ketika aplikasi web Anda mendadak diserang lonjakan trafik—misalnya akibat promosi kilat (flash sale) yang dibagikan oleh influencer—jumlah event yang masuk bisa melonjak dari 100 event per detik menjadi 50.000 event per detik.

Dalam situasi ekstrem ini, satu consumer tunggal di Go dipastikan akan kewalahan. Karena Go dirancang untuk konkurensi tinggi, solusi terbaik adalah menjalankan banyak goroutine worker secara paralel di bawah satu Consumer Group yang sama, di mana masing-masing worker memiliki nama consumer unik:

// Menjalankan 10 worker paralel dalam satu grup
for i := 1; i <= 10; i++ {
    go startWorker(ctx, rdb, fmt.Sprintf("worker-%d", i))
}

Redis Streams secara otomatis akan membagi beban (load balancing) secara adil di antara kesepuluh worker tersebut. Namun, apa yang terjadi jika salah satu worker mengalami kegagalan sistemik saat memproses sebuah event? Di sinilah kita memerlukan strategi penanganan Dead Letter Queue.

8. Jebakan Klasik & Cara Menghindarinya Sebelum Meledak

Kesalahan fatal yang sering dilakukan developer adalah mengasumsikan bahwa semua event pasti berhasil diproses pada percobaan pertama. Padahal, gangguan jaringan sesaat ke database MySQL atau kegagalan koneksi ke API pihak ketiga bisa membuat event gagal diproses.

Jika event gagal dan worker tidak melakukan ACK, event tersebut akan mendekam selamanya di dalam Pending Entries List (PEL). Untuk mengatasinya, kita harus mengimplementasikan mekanisme Claiming (sering disebut PEL reclamation) menggunakan perintah XAutoclaim atau kombinasi XPending dan XClaim.

Berikut adalah pola penanganan Dead Letter Queue (DLQ) sederhana di lapangan:

1. Sebuah event gagal diproses sebanyak 3 kali (kita catat jumlah percobaan di dalam nilai pesan atau tabel terpisah).
2. Daripada membiarkannya retry tanpa henti dan menyumbat antrean utama, kita memindahkan event beracun tersebut ke stream khusus bernama order_events_dlq.
3. Tim engineering dapat melakukan investigasi manual pada data di order_events_dlq tanpa mengganggu kelangsungan operasional sistem utama.

Mari kita uji ketangguhan sistem ini melalui simulasi pengujian performa di titik batas.

9. Uji Nyali: Mengukur Performa di Titik Batas

Sebelum merilis kode ini ke lingkungan produksi yang dilindungi oleh Cloudflare dan Nginx, kita wajib melakukan uji beban (load testing). Kita bisa menggunakan alat seperti k6 atau menulis skrip benchmarking sederhana dalam Go untuk membombardir Redis Streams.

Saat melakukan uji beban dengan 10.000 event per detik, perhatikan beberapa metrik kunci di dalam terminal Redis menggunakan perintah INFO stats dan MEMORY USAGE:

• Total Commands Processed: Pastikan Redis tidak mengalami bottleneck pada CPU tunggalnya (ingat, Redis bersifat single-threaded untuk eksekusi perintah utamanya).
• Connected Clients: Pastikan connection pool Go tidak mengalami lonjakan koneksi yang berujung pada connection refused.
• Stream Length (XINFO STREAM): Pantau panjang total stream. Jika jumlahnya terus bertambah tanpa terkendali, pastikan Anda menerapkan kebijakan pemangkasan (trimming) menggunakan parameter MAXLEN pada perintah XAdd.

// Contoh XAdd dengan pembatasan panjang stream maksimal 100.000 item
_, err := rdb.XAdd(ctx, &redis.XAddArgs{
    Stream: streamKey,
    MaxLen: 100000,
    Approx: true, // ~ memberikan efisiensi memori yang lebih baik
    Values: values,
}).Result()

Setelah pengujian menunjukkan hasil yang memuaskan dan stabil, mari kita rangkum catatan lapangan terakhir sebelum sistem benar-benar mengudara.

10. Catatan Lapangan & Checklist Sebelum Rilis

Menjalankan real-time event-driven pipeline berbasis Redis Streams di produksi menuntut kedisiplinan operasional yang tinggi. Sebelum Anda menekan tombol deploy atau menjalankan skrip Supervisor di server produksi, pastikan checklist berikut sudah dicentang:

1. Persistensi Redis Aktif: Pastikan konfigurasi Redis Anda mengaktifkan AOF (Append Only File) dengan opsi fsync everysec atau snapshotting RDB yang memadai agar data tidak menguap saat server mengalami reboot mendadak.
2. Alokasi RAM yang Cukup: Hitung proyeksi ukuran event harian dan pastikan memori RAM server memiliki sisa setidaknya 40% untuk mengantisipasi lonjakan trafik tak terduga.
3. Graceful Shutdown di Go: Tangkap sinyal sistem (SIGINT, SIGTERM) di aplikasi Go Anda agar worker dapat menyelesaikan pemrosesan event yang sedang berjalan sebelum aplikasi benar-benar dimatikan.
4. Monitoring & Alerting: Pasang metrik Prometheus untuk memantau panjang Consumer Group lag (jumlah pesan tertunda). Jika lag terus membesar, itu adalah sinyal kuat bahwa Anda harus menambah jumlah worker.

Dengan arsitektur yang teruji, penanganan error yang disiplin, dan pemahaman mendalam tentang perilaku Redis Streams di lapangan, sistem backend Go Anda kini siap mengalirkan jutaan event real-time tanpa rasa khawatir. Selamat membangun sistem yang tangguh!