Apa yang sengaja ditunda, lengkap dengan peringatannya

Course ini sengaja menunda beberapa topik agar fokus tetap pada fondasi caching dan state sementara. Bagian ini menyebutnya secara jujur, lengkap dengan peringatan dan arah lanjutan, supaya tidak ada yang hilang diam-diam.

Pub/Sub dan batasannya

Redis Pub/Sub memungkinkan satu proses mem-publish pesan ke channel dan proses lain men-subscribe untuk menerimanya, cocok untuk broadcast realtime ringan seperti memberi tahu antar proses bahwa sebuah cache perlu di-invalidasi. Tetapi menurut dokumentasi Pub/Sub Redis, Pub/Sub bersifat at-most-once: pesan dikirim sekali saja, tidak dipersistensi, dan bila subscriber sedang tidak bisa menerima (error atau disconnect), pesan itu hilang selamanya.

Distributed lock dengan SET NX PX

Lock terdistribusi memakai SET key value NX PX untuk memastikan hanya satu proses memegang lock pada satu waktu, dengan expiry (PX) dan token kepemilikan agar unlock aman. Ide ini menggoda, tetapi mudah salah.

Cache stampede dan singleflight

Cache stampede terjadi ketika banyak request miss bersamaan (mis. tepat saat key kedaluwarsa) lalu serentak menyerang database, mengubah cache miss jadi database spike. Ini persis badai miss yang jitter TTL di Chapter 3 baru meredam, belum menuntaskan. Solusi di Go adalah menekan panggilan duplikat dengan golang.org/x/sync/singleflight, yang menyediakan Group.Do: untuk key yang sama, fungsi dieksekusi sekali dan hasilnya dibagikan ke semua pemanggil konkuren.

internal/product/singleflight.goSalin
import "golang.org/x/sync/singleflight"

var group singleflight.Group

// GetByIDDeduped memastikan hanya satu pengambilan database per key
// walau banyak request miss bersamaan.
func (s *Service) GetByIDDeduped(ctx context.Context, id int64) (Product, error) {
	key := productKey(id)
	v, err, _ := group.Do(key, func() (any, error) {
		return s.GetByIDResilient(ctx, id)
	})
	if err != nil {
		return Product{}, err
	}
	return v.(Product), nil
}

Selain singleflight, teknik pelengkap adalah pola stale-while-revalidate yang menyajikan data lama sebentar sambil menyegarkan di latar.

Redis Streams dan consumer group

Stream adalah log append-only untuk event processing. Berbeda dari Pub/Sub, pesan di Stream dipersistensi dan mendukung at-least-once, sehingga cocok untuk event-driven backend dan worker. Consumer group memungkinkan banyak worker membagi beban membaca event yang sama, dengan pending messages dan acknowledgement agar tidak ada event yang hilang. Ini adalah pintu masuk ke materi scaling berikutnya.

Itu semua peta jalan ke depan. Sekarang mari menoleh ke belakang dan merangkai seluruh course menjadi satu gambar utuh.

Pakai Redis di tempat yang benar, bukan di mana-mana

Seluruh materi bermuara pada satu prinsip: pakai Redis di tempat yang benar, bukan di mana-mana. Redis adalah tool performa dan state sementara, bukan pengganti desain database yang benar.

Mari petakan ke empat flow nyata online shop. Pada detail produk, cache-aside dengan TTL dan delete-on-write membuat database tidak menjadi titik panas. Pada login, rate limit INCR+EXPIRE melindungi dari brute force, dan session disimpan di Redis dengan TTL alami. Pada checkout, Redis boleh membatasi laju, tetapi pengurangan stok dan pembuatan order tetap transaksi PostgreSQL. Pada admin update product, tulis ke PostgreSQL dulu lalu hapus product:{id} agar pembaca berikutnya mendapat data segar.

flowchart TD
  PD["Detail produk"] --> CA["cache-aside + TTL + delete-on-write"]
  LG["Login"] --> RT["rate limit + session store"]
  CO["Checkout"] --> TX["rate limit di Redis, stok & order di PostgreSQL"]
  AU["Admin update product"] --> INV["tulis DB dulu, lalu DEL cache"]

Gambar 1. Empat flow, satu prinsip: Redis mempercepat dan menyimpan sementara; PostgreSQL menjaga kebenaran.

Langkah berikutnya menuju backend high-traffic adalah memperdalam caching strategy (stampede protection, stale-while-revalidate), membangun worker dan event-driven flow dengan Redis Streams, serta merancang observability yang matang. Tetapi prinsip yang kamu pegang di sini tidak berubah: tempatkan Redis di tempat yang benar, jaga PostgreSQL tetap menjadi sumber kebenaran, dan biarkan kecepatan datang dari desain yang disiplin, bukan dari cache yang dipasang di mana-mana.