Belajar Redis dengan Go
Cepat di Tempat yang Benar

Akselerator opsional, bukan sumber kebenaran

Redis adalah penyimpanan key-value berbasis memori yang sangat cepat. Ia menolong untuk cache, session, rate limit, dan data sementara, tetapi ia bukan pengganti PostgreSQL untuk data bisnis yang harus permanen dan konsisten.

Banyak masalah performa backend berbentuk sama: satu query database yang sama dijalankan ribuan kali untuk data yang jarang berubah. Halaman detail produk, daftar kategori, dan profil publik dibaca jauh lebih sering daripada diubah. Di sinilah Redis bersinar. Ia menyimpan hasil di memori dan mengembalikannya dalam hitungan mikrodetik, sehingga database tidak menjadi titik panas tiap request.

Tetapi kecepatan itu datang dengan syarat. Redis menyimpan salinan data, dan salinan bisa basi. Begitu kamu menaruh data yang sensitif terhadap konsistensi (stok, status pesanan, status pembayaran) di Redis tanpa disiplin, kamu menukar bug yang jarang dengan bug yang sering, dan biasanya bug yang merugikan uang. Aturan mental yang dipegang sepanjang course ini: Redis adalah akselerator opsional, bukan sumber kebenaran.

flowchart LR
  Client["Frontend"] -->|HTTP JSON| API["Go API"]
  API -->|cek dulu| Redis[("Redis (memory)")]
  Redis -.->|miss| DB[("PostgreSQL (sumber kebenaran)")]
  API -->|tulis bisnis| DB
  Redis -->|hit cepat| API

Gambar 1. Redis duduk di depan PostgreSQL sebagai akselerator baca. PostgreSQL tetap satu-satunya sumber kebenaran untuk data bisnis.

Berpikir memory-first sebelum menghafal command

Sebelum menghafal command, pegang model intinya: Redis adalah peta besar dari key ke value yang hidup di memori, dan setiap key bisa diberi waktu hidup (TTL) yang otomatis menghapusnya saat kedaluwarsa.

Tiga konsep ini lebih dulu dari sintaks command apa pun. Key adalah string unik yang menjadi alamat data. Value adalah isinya, yang bisa berupa string, hash, list, set, dan tipe lain. TTL adalah durasi sebelum key dihapus sendiri. Begitu kamu berpikir dalam tiga kata ini, sebagian besar keputusan caching jadi jelas.

Key yang baik bersifat deskriptif dan berpola namespace, dipisah titik dua. Pola entitas:id atau entitas:id:atribut membuat key mudah dibaca manusia dan mudah dikelola. Contohnya product:123 untuk detail produk, category:list untuk daftar kategori, dan session:abc123 untuk sesi login.

TTL adalah fitur yang membuat Redis ideal untuk data sementara. Kamu tidak perlu job pembersih yang menghapus data lama; Redis melakukannya sendiri. Inilah alasan session, rate limit window, dan cache berumur pendek terasa alami di Redis.

flowchart TD
  Set["SET product:123 (JSON) EX 300"] --> Live["Key hidup di memori"]
  Live -->|dalam 300 detik| Hit["GET product:123 -> value"]
  Live -->|lewat 300 detik| Expired["Key terhapus otomatis"]
  Expired --> Miss["GET product:123 -> nil (miss)"]

Gambar 2. Siklus hidup satu key dengan TTL 5 menit. Setelah kedaluwarsa, key hilang sendiri tanpa job pembersih.

Sebagai latihan model pikir, bayangkan menyimpan detail produk dengan TTL 5 menit. Selama 5 menit pertama, semua request membaca dari memori. Setelah itu, request pertama yang datang akan miss, mengambil ulang dari database, lalu mengisi cache lagi. Toleransi 5 menit ini adalah keputusan bisnis: harga dan deskripsi produk yang telat 5 menit hampir tidak pernah merugikan, dan inilah kandidat cache yang sehat.

Satu peta keputusan: pilih tipe sebelum menulis command

Redis bukan sekadar penyimpan string. Ia punya beberapa tipe data inti, dan memilih tipe yang tepat adalah keputusan desain yang lebih penting daripada hafal sintaks command.

Menurut dokumentasi Redis, tipe inti yang sering dipakai adalah String, Hash, List, Set, Sorted Set, dan Stream. Tiap tipe punya kasus pakai yang berbeda. Jangan memaksakan satu tipe untuk semua; pilih berdasar bentuk data dan operasi yang dibutuhkan.

String vs Hash untuk object

Untuk menyimpan satu produk, ada dua pilihan umum. String JSON menyimpan seluruh produk sebagai satu blob JSON. Hash menyimpan tiap field terpisah dalam satu key. Pilihannya bergantung pada apakah kamu sering memperbarui satu field saja.

Untuk cache-aside produk yang dibaca utuh lalu dikirim ke frontend, String JSON biasanya lebih praktis karena satu kali GET dan satu kali decode. Hash menang ketika kamu butuh memperbarui atau membaca sebagian field tanpa memuat seluruh object.

List vs Stream untuk urutan event

List bisa dipakai sebagai antrian sederhana: LPUSH di satu ujung, BRPOP di ujung lain. Ini cukup untuk tugas ringan. Tetapi begitu kamu butuh banyak consumer yang membaca event yang sama, perlu acknowledgement, atau perlu memutar ulang event, List mulai kewalahan. Di titik itu, Stream adalah jawabannya.

Redis Streams didesain sebagai struktur data append-only log untuk event processing, dengan dukungan consumer group dan pending messages. Detail consumer group sengaja kita tunda ke section Topik Lanjutan agar fokus section ini tetap pada pemilihan tipe.

Set dan Sorted Set untuk fitur cepat

Set menyimpan anggota unik tanpa urutan, ideal untuk daftar favorit user (SADD favorites:user:42 product:123) karena SADD otomatis menolak duplikat. Sorted Set menambahkan score ke tiap anggota dan menjaganya tetap terurut, ideal untuk ranking seperti produk paling banyak dilihat (ZADD top:viewed 1 product:123, lalu ZREVRANGE untuk ambil teratas).

Client resmi, context sebagai parameter pertama

Client Go resmi untuk Redis adalah github.com/redis/go-redis/v9. Versi terbaru saat course ini ditulis adalah v9.20.1 (rilis 11 Juni 2026), berlisensi BSD-2-Clause.

Pola di go-redis konsisten: setiap command menerima context.Context sebagai parameter pertama, lalu argumen command, dan mengembalikan sebuah objek hasil yang nilainya diambil lewat .Result() atau .Err(). Karena context jadi parameter pertama, kamu bisa memasang timeout dan pembatalan dengan rapi, persis seperti pada query pgx di modul PostgreSQL.

Pertama, pasang dependency.

TerminalSalin
go get github.com/redis/go-redis/v9@v9.20.1

Lalu buat client. redis.NewClient menerima *redis.Options, dan untuk lokal cukup mengisi Addr. Setelah itu, Ping memverifikasi koneksi.

internal/cache/redis.goSalin
package cache

import (
	"context"
	"time"

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

// New membuat client Redis dan memverifikasi koneksi dengan Ping.
func New(ctx context.Context, addr string) (*redis.Client, error) {
	client := redis.NewClient(&redis.Options{
		Addr: addr,
	})

	pingCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
	defer cancel()

	if err := client.Ping(pingCtx).Err(); err != nil {
		return nil, err
	}

	return client, nil
}

Sekarang operasi dasar Set dan Get. Perhatikan context.WithTimeout per operasi dan penanganan redis.Nil sebagai cache miss, bukan error.

internal/cache/redis.goSalin
import (
	"context"
	"errors"
	"time"

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

// SetString menyimpan value string dengan TTL.
func SetString(ctx context.Context, client *redis.Client, key, value string, ttl time.Duration) error {
	ctx, cancel := context.WithTimeout(ctx, 200*time.Millisecond)
	defer cancel()

	return client.Set(ctx, key, value, ttl).Err()
}

// GetString mengembalikan value, found=false bila key tidak ada (cache miss).
func GetString(ctx context.Context, client *redis.Client, key string) (value string, found bool, err error) {
	ctx, cancel := context.WithTimeout(ctx, 200*time.Millisecond)
	defer cancel()

	value, err = client.Get(ctx, key).Result()
	if errors.Is(err, redis.Nil) {
		return "", false, nil // cache miss, bukan error
	}
	if err != nil {
		return "", false, err // error sungguhan (timeout, koneksi putus)
	}
	return value, true, nil
}

flowchart TD
  Get["client.Get(ctx, key).Result()"] --> Check{"err?"}
  Check -->|err == nil| Hit["value valid (cache hit)"]
  Check -->|errors.Is err redis.Nil| Miss["cache miss (normal)"]
  Check -->|err lain| Fail["error nyata: timeout / koneksi"]

Gambar 3. Tiga cabang hasil dari satu Get. Hanya cabang paling kanan yang benar-benar kegagalan.

Cek Redis dulu, miss baru ke PostgreSQL, lalu isi cache

Cache-aside adalah pola caching paling umum dan paling aman untuk dipelajari pertama: aplikasi mengecek Redis dulu, kalau miss baru mengambil dari PostgreSQL, lalu mengisi Redis untuk request berikutnya.

Disebut “aside” karena cache berdiri di samping database, bukan di tengah jalur tulis. Aplikasi yang memegang kendali kapan membaca dan kapan mengisi cache. Pola ini cocok untuk data baca-berat yang jarang berubah, seperti detail produk.

sequenceDiagram
  participant H as Handler
  participant R as Redis
  participant DB as PostgreSQL
  H->>R: GET product:123
  alt cache hit
    R-->>H: JSON produk
  else cache miss
    R-->>H: nil
    H->>DB: SELECT produk WHERE id=123
    DB-->>H: row produk
    H->>R: SET product:123 (JSON) EX 300
    H-->>H: kembalikan produk
  end

Gambar 4. Alur cache-aside. Database hanya tersentuh saat miss, sehingga ia tidak menjadi titik panas tiap request.

Berikut penerapan pada GET /v1/products/:id tanpa mengubah kontrak API. Service mencoba cache lebih dulu, jatuh ke repository bila miss, lalu menyimpan hasilnya.

internal/product/service.goSalin
package product

import (
	"context"
	"encoding/json"
	"errors"
	"time"

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

const productTTL = 5 * time.Minute

type Repository interface {
	FindByID(ctx context.Context, id int64) (Product, error)
}

type Service struct {
	repo  Repository
	redis *redis.Client
}

func NewService(repo Repository, rdb *redis.Client) *Service {
	return &Service{repo: repo, redis: rdb}
}

// GetByID menerapkan cache-aside: cek Redis, miss baru ke PostgreSQL.
func (s *Service) GetByID(ctx context.Context, id int64) (Product, error) {
	key := productKey(id)

	// 1. Cek cache.
	cached, err := s.redis.Get(ctx, key).Result()
	if err == nil {
		var p Product
		if jsonErr := json.Unmarshal([]byte(cached), &p); jsonErr == nil {
			return p, nil // cache hit
		}
		// JSON rusak: anggap miss, lanjut ke database.
	} else if !errors.Is(err, redis.Nil) {
		// Error Redis nyata: jangan gagalkan request, lanjut ke database.
		// (Resilience dibahas di section 12.)
	}

	// 2. Cache miss: ambil dari sumber kebenaran.
	p, err := s.repo.FindByID(ctx, id)
	if err != nil {
		return Product{}, err
	}

	// 3. Isi cache untuk request berikutnya (best-effort).
	if blob, marshalErr := json.Marshal(p); marshalErr == nil {
		_ = s.redis.Set(ctx, key, blob, productTTL).Err()
	}

	return p, nil
}

func productKey(id int64) string {
	return "product:" + itoa(id)
}

Key yang konsisten menentukan kemudahan invalidasi

Key yang dirancang dengan disiplin menentukan seberapa mudah kamu menghapus dan memperbarui cache nanti. Key yang berantakan membuat invalidasi jadi mimpi buruk.

Key yang baik punya struktur yang konsisten dan dapat ditebak. Pola yang umum dan kuat adalah menyusun komponen yang dipisah titik dua, dari yang paling umum ke paling spesifik.

Dengan pola itu, beberapa contoh key untuk online shop terlihat seperti ini.

Contoh cache keySalin
prod:v1:product:123                detail produk id 123
prod:v1:category:list              daftar kategori
prod:v1:search:8f3a1c              hasil pencarian (8f3a1c = hash query)
prod:v1:session:abc123             sesi login

Untuk hasil yang bergantung pada banyak parameter (pencarian dengan filter dan paginasi), jangan menempelkan seluruh query mentah ke key karena panjang dan rawan karakter aneh. Buat hash pendek yang deterministik dari parameter yang sudah dinormalkan.

internal/product/cachekey.goSalin
package product

import (
	"crypto/sha1"
	"encoding/hex"
	"fmt"
)

// searchKey membuat key stabil dari parameter pencarian yang sudah dinormalkan.
func searchKey(env, q, category string, page int) string {
	raw := fmt.Sprintf("q=%s&cat=%s&page=%d", q, category, page)
	sum := sha1.Sum([]byte(raw))
	short := hex.EncodeToString(sum[:])[:6]
	return fmt.Sprintf("%s:v1:search:%s", env, short)
}

Kapan data cache dianggap basi dan bagaimana membuangnya

Pertanyaan tersulit dalam caching bukan cara menyimpan, melainkan kapan data cache dianggap basi dan bagaimana membuangnya. Ada dua alat utama: TTL dan penghapusan eksplisit saat data berubah.

TTL membuat cache kedaluwarsa sendiri setelah durasi tertentu. Ini cocok untuk data yang boleh sedikit telat. Penghapusan eksplisit (delete-on-write) membuang key cache segera setelah sumbernya berubah, sehingga request berikutnya pasti mengambil data segar. Keduanya sering dipakai bersama.

Pola paling jelas untuk online shop adalah menghapus product:{id} setelah admin memperbarui produk. Update menulis ke PostgreSQL dulu (sumber kebenaran), baru menghapus cache. Urutan ini penting: tulis dulu, baru buang cache.

internal/product/service.goSalin
// Update menulis ke PostgreSQL lalu membuang cache produk terkait.
func (s *Service) Update(ctx context.Context, p Product) error {
	// 1. Tulis ke sumber kebenaran dulu.
	if err := s.repo.Update(ctx, p); err != nil {
		return err
	}

	// 2. Buang cache (best-effort). Request berikutnya akan miss
	//    lalu mengisi ulang dari data yang sudah segar.
	_ = s.redis.Del(ctx, productKey(p.ID)).Err()

	return nil
}

sequenceDiagram
  participant Admin as Admin
  participant API as Go API
  participant DB as PostgreSQL
  participant R as Redis
  Admin->>API: PATCH /v1/admin/products/123
  API->>DB: UPDATE produk SET ... WHERE id=123
  DB-->>API: ok
  API->>R: DEL product:123
  API-->>Admin: 200 OK
  Note over R: request baca berikutnya miss,<br/>isi ulang dari data segar

Gambar 5. Delete-on-write. Tulis ke PostgreSQL dulu, baru hapus cache, agar tidak ada jendela di mana cache terisi data lama setelah database sudah baru.

Melawan refleks cache semua GET

Section ini adalah pertahanan. Tidak semua data layak di-cache, dan beberapa data justru berbahaya bila di-cache. Mengetahui apa yang tidak boleh di-cache sama pentingnya dengan tahu cara cache.

Aturan keputusannya sederhana: cache aman untuk data yang jarang berubah dan tidak merugikan bila telat. Cache berbahaya untuk data yang harus selalu akurat saat itu juga, terutama yang menyangkut uang, stok, dan status transaksi.

flowchart TD
  Q{"Data ini kalau telat<br/>beberapa menit,<br/>siapa yang rugi?"}
  Q -->|tidak ada yang rugi| Cache["Aman di-cache dengan TTL"]
  Q -->|UX sedikit terganggu| Careful["Hati-hati: TTL pendek + awasi"]
  Q -->|pelanggan atau uang rugi| NoCache["JANGAN cache sebagai kebenaran"]

Gambar 6. Pohon keputusan satu pertanyaan yang bisa langsung dipakai tim sebelum memutuskan cache.

Memanfaatkan operasi atomic untuk membatasi laju request

Redis sangat cocok untuk rate limiting karena INCR bersifat atomic: menaikkan counter aman walau banyak request datang bersamaan, sehingga hitungan tidak pernah salah karena race.

Pola paling sederhana adalah fixed window: untuk tiap kombinasi subjek dan jendela waktu, naikkan counter, dan bila ini kenaikan pertama, pasang TTL sepanjang jendela. Saat counter melewati batas, tolak request dengan status 429.

internal/ratelimit/fixedwindow.goSalin
package ratelimit

import (
	"context"
	"time"

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

// Allow menaikkan counter untuk key di jendela tetap.
// Mengembalikan true bila request masih di bawah limit.
func Allow(ctx context.Context, rdb *redis.Client, key string, limit int64, window time.Duration) (bool, error) {
	count, err := rdb.Incr(ctx, key).Result()
	if err != nil {
		return false, err
	}

	// Saat counter baru dibuat (nilai 1), pasang TTL jendela.
	if count == 1 {
		if err := rdb.Expire(ctx, key, window).Err(); err != nil {
			return false, err
		}
	}

	return count <= limit, nil
}

Karena INCR mengembalikan nilai baru secara atomic, dua request bersamaan tidak akan membaca nilai lama yang sama lalu menimpanya. Inilah yang membuat counter aman tanpa lock manual.

sequenceDiagram
  participant U as User
  participant API as Go API
  participant R as Redis
  U->>API: POST /v1/auth/login
  API->>R: INCR ratelimit:login:ip:1.2.3.4
  R-->>API: count = 1
  API->>R: EXPIRE key 60s (karena count==1)
  API-->>U: lanjut proses login
  Note over U,R: request ke-6 dalam 60 detik
  U->>API: POST /v1/auth/login
  API->>R: INCR key
  R-->>API: count = 6 (> limit 5)
  API-->>U: 429 Too Many Requests

Gambar 7. Fixed window limit 5 per 60 detik pada login per-IP. Request keenam ditolak sampai jendela reset.

Terapkan ini ke endpoint sensitif seperti login (per-IP, melawan brute force) dan checkout (per-user, melawan klik ganda atau abuse). Kunci key membedakan subjek: ratelimit:login:ip:{ip} dan ratelimit:checkout:user:{id}.

State autentikasi sementara dengan TTL alami

Redis ideal untuk session store dan token blacklist karena keduanya secara alami punya masa hidup. TTL Redis menghapus session kedaluwarsa dan token tercabut tanpa job pembersih.

Session adalah state autentikasi sementara: ID acak yang menunjuk ke data user yang sedang login, dengan TTL sebagai masa berlaku. Token blacklist menyimpan token yang sengaja dicabut (mis. setelah logout) sampai token itu kedaluwarsa sendiri. Keduanya bukan sumber kebenaran identitas; identitas tetap ada di PostgreSQL.

internal/auth/session.goSalin
package auth

import (
	"context"
	"encoding/json"
	"errors"
	"time"

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

const sessionTTL = 24 * time.Hour

type Session struct {
	UserID int64  `json:"user_id"`
	Role   string `json:"role"`
}

type Store struct {
	redis *redis.Client
}

func NewStore(rdb *redis.Client) *Store {
	return &Store{redis: rdb}
}

// Save menyimpan session dengan TTL.
func (s *Store) Save(ctx context.Context, id string, sess Session) error {
	blob, err := json.Marshal(sess)
	if err != nil {
		return err
	}
	return s.redis.Set(ctx, "session:"+id, blob, sessionTTL).Err()
}

// Get membaca session; found=false bila tidak ada atau sudah kedaluwarsa.
func (s *Store) Get(ctx context.Context, id string) (Session, bool, error) {
	blob, err := s.redis.Get(ctx, "session:"+id).Result()
	if errors.Is(err, redis.Nil) {
		return Session{}, false, nil
	}
	if err != nil {
		return Session{}, false, err
	}
	var sess Session
	if err := json.Unmarshal([]byte(blob), &sess); err != nil {
		return Session{}, false, err
	}
	return sess, true, nil
}

// Touch memperpanjang masa hidup session yang masih aktif.
func (s *Store) Touch(ctx context.Context, id string) error {
	return s.redis.Expire(ctx, "session:"+id, sessionTTL).Err()
}

// Revoke menghapus session saat logout.
func (s *Store) Revoke(ctx context.Context, id string) error {
	return s.redis.Del(ctx, "session:"+id).Err()
}

stateDiagram-v2
  [*] --> Aktif: login (Save, TTL 24 jam)
  Aktif --> Aktif: request (Touch, perpanjang TTL)
  Aktif --> Habis: TTL kedaluwarsa
  Aktif --> Dicabut: logout (Revoke / Del)
  Habis --> [*]
  Dicabut --> [*]

Gambar 8. Siklus hidup session. TTL menghapus session diam yang tidak aktif; logout mencabut segera.

Atomicity Redis lebih terbatas dari transaksi PostgreSQL

Banyak command Redis bersifat atomic per command, tetapi menggabungkan beberapa langkah jadi satu unit yang aman butuh desain. Atomicity Redis lebih terbatas dibanding transaksi PostgreSQL.

Ada tiga tingkat. Pertama, command tunggal seperti INCR sudah atomic, jadi counter dan flag aman tanpa usaha tambahan. Kedua, MULTI/EXEC (lewat TxPipelined di go-redis) mengirim beberapa command sebagai satu blok yang dijalankan berurutan tanpa disela command lain. Ketiga, optimistic transaction dengan WATCH (lewat client.Watch) untuk operasi baca-ubah-tulis yang harus gagal bila data berubah di tengah.

Untuk command atomic tunggal seperti counter view produk, cukup INCR. Tidak perlu transaksi.

internal/product/views.goSalin
// IncrViews menaikkan penghitung tampilan produk secara atomic.
func IncrViews(ctx context.Context, rdb *redis.Client, productID int64) (int64, error) {
	return rdb.Incr(ctx, viewsKey(productID)).Result()
}

Untuk beberapa command yang harus berjalan sebagai satu blok, pakai TxPipelined. Contoh: menaikkan counter rate limit dan memasang TTL dalam satu kirim.

internal/ratelimit/pipeline.goSalin
import "github.com/redis/go-redis/v9"

// AllowPipelined menjalankan INCR + EXPIRE sebagai satu blok MULTI/EXEC.
func AllowPipelined(ctx context.Context, rdb *redis.Client, key string, limit int64, window time.Duration) (bool, error) {
	var incr *redis.IntCmd
	_, err := rdb.TxPipelined(ctx, func(pipe redis.Pipeliner) error {
		incr = pipe.Incr(ctx, key)
		pipe.Expire(ctx, key, window)
		return nil
	})
	if err != nil {
		return false, err
	}
	return incr.Val() <= limit, nil
}

Untuk baca-ubah-tulis yang harus konsisten, pakai client.Watch. Menurut panduan transaksi Redis, bila key yang di-WATCH berubah sebelum Exec, transaksi gagal dengan redis.TxFailedErr dan perlu di-retry dalam loop.

internal/cache/optimistic.goSalin
import (
	"context"
	"errors"

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

// IncrementBy melakukan baca-ubah-tulis aman dengan optimistic transaction.
func IncrementBy(ctx context.Context, rdb *redis.Client, key string, delta int64) error {
	const maxRetries = 3

	txf := func(tx *redis.Tx) error {
		current, err := tx.Get(ctx, key).Int64()
		if err != nil && !errors.Is(err, redis.Nil) {
			return err
		}
		next := current + delta
		// Exec hanya jalan bila key yang di-WATCH tidak berubah.
		_, err = tx.TxPipelined(ctx, func(pipe redis.Pipeliner) error {
			pipe.Set(ctx, key, next, 0)
			return nil
		})
		return err
	}

	for i := 0; i < maxRetries; i++ {
		err := rdb.Watch(ctx, txf, key)
		if err == nil {
			return nil // sukses
		}
		if errors.Is(err, redis.TxFailedErr) {
			continue // key berubah, coba lagi
		}
		return err // error nyata
	}
	return errors.New("optimistic transaction gagal setelah retry")
}

flowchart TD
  Watch["WATCH key"] --> Read["baca nilai sekarang"]
  Read --> Compute["hitung nilai baru"]
  Compute --> Exec["EXEC (TxPipelined)"]
  Exec --> Check{"key berubah<br/>saat di-WATCH?"}
  Check -->|tidak| Done["sukses"]
  Check -->|ya: redis.TxFailedErr| Retry["retry dari WATCH"]
  Retry --> Watch

Gambar 9. Pola optimistic transaction. Bila ada yang menyentuh key di tengah, EXEC gagal dan kita ulang dari WATCH.

Redis boleh gagal tanpa menjatuhkan API, dan harus dipantau

Redis adalah akselerator, jadi ia boleh gagal tanpa membuat API ikut gagal. Bila Redis mati, API harus tetap melayani request dari PostgreSQL, sedikit lebih lambat. Dan agar tahu cache benar-benar menolong, ia harus dipantau.

Inti resilience adalah membedakan cache error dari business error. Cache error (Redis timeout, koneksi putus) tidak boleh menggagalkan request; ia hanya berarti “lewati cache kali ini, ambil dari database”. Business error (produk tidak ada, validasi gagal) adalah hasil sah yang memang harus dikembalikan ke client.

Pola fallback: coba cache dengan timeout pendek, dan apa pun yang bukan cache hit (miss atau error) jatuh ke database. Inilah yang membuat Redis bukan single point of failure.

internal/product/service.goSalin
// GetByIDResilient memperlakukan kegagalan Redis sebagai miss, bukan error fatal.
func (s *Service) GetByIDResilient(ctx context.Context, id int64) (Product, error) {
	key := productKey(id)

	// Timeout pendek khusus cache: kalau Redis lambat, jangan tahan request.
	cacheCtx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
	cached, err := s.redis.Get(cacheCtx, key).Result()
	cancel()

	switch {
	case err == nil:
		var p Product
		if json.Unmarshal([]byte(cached), &p) == nil {
			s.metrics.RecordHit()
			return p, nil
		}
	case errors.Is(err, redis.Nil):
		s.metrics.RecordMiss()
	default:
		// Redis error (timeout, koneksi): catat, lalu lanjut ke database.
		s.metrics.RecordError()
		s.log.Warn("redis get gagal, fallback ke database", "key", key, "err", err)
	}

	// Sumber kebenaran selalu tersedia walau Redis bermasalah.
	p, dbErr := s.repo.FindByID(ctx, id)
	if dbErr != nil {
		return Product{}, dbErr
	}

	// Isi cache best-effort; abaikan error.
	if blob, mErr := json.Marshal(p); mErr == nil {
		setCtx, c := context.WithTimeout(ctx, 100*time.Millisecond)
		_ = s.redis.Set(setCtx, key, blob, productTTL).Err()
		c()
	}

	return p, nil
}

flowchart TD
  Req["GET /v1/products/123"] --> Try["coba Redis (timeout 100ms)"]
  Try --> R{"hasil?"}
  R -->|hit| Fast["balas cepat dari cache"]
  R -->|miss| DB["ambil dari PostgreSQL"]
  R -->|error / timeout| DB
  DB --> Resp["balas dari database"]
  DB --> Fill["isi cache best-effort"]

Gambar 10. Dengan fallback, mematikan Redis hanya membuat lebih banyak request menyentuh PostgreSQL. API tetap hidup.

Observability: tahu cache benar-benar efektif

Cache yang tidak dipantau adalah kotak ajaib. Metrik inti yang menentukan apakah cache efektif adalah hit rate (rasio hit terhadap total), latency pemanggilan Redis, pemakaian memori, eviction (key terbuang karena memori penuh), dan slowlog (command yang lambat).

Yang paling mudah dikontrol dari sisi aplikasi adalah hit rate dan latency. Catat hit, miss, dan error di service (seperti RecordHit/RecordMiss di kode di atas), lalu ukur durasi tiap pemanggilan Redis.

internal/cache/instrument.goSalin
// timed mengukur durasi satu operasi Redis untuk metrik latency.
func timed(name string, log *slog.Logger, fn func() error) error {
	start := time.Now()
	err := fn()
	log.Info("redis op", "op", name, "ms", time.Since(start).Milliseconds(), "err", err)
	return err
}

Redis di Docker Compose plus peta di mana ia dipasang

Bagian ini menyatukan dua hal praktis: menambahkan Redis ke stack lokal lewat Docker Compose, dan memetakan di mana saja Redis dipakai (dan tidak dipakai) di online shop skincare.

Redis mudah dijalankan lokal bersama Go API dan PostgreSQL. Tambahkan satu service ringkas ke docker-compose.yml, dengan env REDIS_ADDR yang dibaca aplikasi.

docker-compose.ymlSalin
services:
  api:
    build: .
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgres://app:secret@postgres:5432/skincare?sslmode=disable
      REDIS_ADDR: redis:6379
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:17
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: skincare
    ports:
      - "5432:5432"

  redis:
    image: redis:7
    ports:
      - "6379:6379"

cmd/api/main.goSalin
// Baca alamat Redis dari environment, dengan default lokal yang masuk akal.
addr := os.Getenv("REDIS_ADDR")
if addr == "" {
	addr = "localhost:6379"
}

rdb, err := cache.New(ctx, addr)
if err != nil {
	// Redis opsional: log peringatan, tetap jalan tanpa cache bila perlu.
	log.Printf("redis tidak tersedia, jalan tanpa cache: %v", err)
}

Peta penggunaan Redis di online shop

Berikut peta selektif: bagian mana memakai Redis, dan bagian mana tetap murni di PostgreSQL. Ini ringkasan keputusan dari seluruh course.

flowchart LR
  subgraph Redis["Redis (akselerator + state sementara)"]
    PC["product / category cache"]
    SS["user session"]
    RL["login / checkout throttle"]
    TV["top viewed (sorted set)"]
  end
  subgraph PG["PostgreSQL (sumber kebenaran)"]
    INV["inventory / stok"]
    ORD["order + payment status"]
    CART["cart aktif"]
  end
  API["Go API"] --> Redis
  API --> PG

Gambar 11. Peta penggunaan. Redis memegang yang cepat dan sementara; PostgreSQL memegang yang harus benar dan permanen.

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. 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 memberi jitter (sedikit variasi acak) pada TTL agar banyak key tidak kedaluwarsa di detik yang sama, dan 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.

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 12. 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.