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 1. 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
}

Atur memori: maxmemory dan eviction policy

Metrik eviction di tabel di atas baru bermakna kalau Redis tahu kapan harus meng-evict. Saat Redis dipakai murni sebagai cache, praktik produksi yang penting adalah memberi batas memori (maxmemory) dan kebijakan eviction yang membuang key paling tidak berguna ketika batas tercapai, alih-alih membiarkan Redis kehabisan memori dan ditolak oleh OS. Untuk cache, kebijakan yang umum adalah allkeys-lru (buang key yang paling lama tidak diakses) atau allkeys-lfu (buang yang paling jarang diakses).

redis.conf (potongan untuk peran cache)Salin
maxmemory 512mb
maxmemory-policy allkeys-lru

Resilience dan observability memastikan Redis berperilaku baik di produksi. Tetapi sebelum produksi ada development, dan di sanalah kita harus bisa menyalakan seluruh stack dengan mudah.

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 2. Peta penggunaan. Redis memegang yang cepat dan sementara; PostgreSQL memegang yang harus benar dan permanen.

Peta ini adalah seluruh course dalam satu tabel: tiap “Ya” adalah teknik yang sudah kita pelajari, tiap “Tidak” adalah garis disiplin yang kita jaga. Chapter terakhir merangkum semuanya dan menunjuk ke topik lanjutan yang sengaja kita tunda.

Redis yang aman di produksi

Chapter ini menyiapkan Redis untuk produksi: gagal dengan anggun, terpantau, terkendali memorinya, dan mudah dinyalakan di stack lokal.

Kita bangun fallback yang memperlakukan kegagalan Redis sebagai cache miss, dengan timeout pendek agar Redis yang lambat tidak menahan request, sehingga API tetap hidup dari PostgreSQL. Kita pantau hit rate, latency, memori, eviction, dan slowlog, lalu mengatur maxmemory plus allkeys-lru agar Redis membuang cache lama dengan tenang saat penuh. Terakhir kita rakit stack Go plus PostgreSQL plus Redis dengan Docker Compose dan memetakan di mana Redis dipakai (cache, session, rate limit, ranking) dan di mana tidak (stok, order, payment, cart).

Redis kini siap produksi: cepat saat sehat, aman saat gagal. Di Chapter 6 kita menutup course dengan jujur menyebut topik yang sengaja ditunda (Pub/Sub, distributed lock, cache stampede, Streams) lengkap dengan peringatannya, lalu merangkum seluruh perjalanan ke dalam empat flow nyata online shop.