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)
}

Key yang konsisten baru separuh cerita. Pertanyaan yang lebih sulit adalah: setelah disimpan, kapan isinya dianggap basi, dan bagaimana membuangnya?

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 1. Delete-on-write. Tulis ke PostgreSQL dulu, baru hapus cache, agar tidak ada jendela di mana cache terisi data lama setelah database sudah baru.

Jitter TTL: menghindari kedaluwarsa berjamaah

Ada jebakan halus pada TTL yang seragam. Bila ribuan key dibuat dalam lonjakan yang sama (misalnya saat cache dingin setelah deploy lalu langsung diserbu traffic), semuanya akan kedaluwarsa nyaris bersamaan pula. Saat detik kedaluwarsa itu tiba, semua request miss serentak dan menyerbu database sekaligus. Dalam skenario nyata, satu hot key di endpoint 10k request per detik dengan TTL 60 detik bisa mengirim ribuan query ke database dalam satu detik begitu key itu kedaluwarsa di semua tempat sekaligus.

Penangkal paling murah adalah memberi sedikit variasi acak (jitter) pada TTL, misalnya 300 detik plus 0 sampai 60 detik acak, sehingga key tersebar kedaluwarsanya alih-alih meledak bersamaan.

internal/cache/ttl.goSalin
import (
	"math/rand/v2"
	"time"
)

// withJitter menambah variasi acak agar key tidak kedaluwarsa serentak.
func withJitter(base time.Duration, spread time.Duration) time.Duration {
	return base + time.Duration(rand.Int64N(int64(spread)))
}

// pemakaian: TTL 5 menit + 0..60 detik acak.
// ttl := withJitter(5*time.Minute, 60*time.Second)

Sampai sini kita sudah tahu cara cache yang benar. Tetapi keterampilan yang sama pentingnya adalah tahu kapan TIDAK cache sama sekali.

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 2. Pohon keputusan satu pertanyaan yang bisa langsung dipakai tim sebelum memutuskan cache.

Pohon keputusan satu pertanyaan ini adalah inti seluruh chapter: cache memperbaiki performa hanya bila dipasang pada data yang benar. Itu pula yang membedakan caching yang menolong dari caching yang merugikan.

Cache yang benar, bukan sekadar cepat

Chapter ini mengubah cache-aside dari “bekerja” menjadi “benar” lewat tiga lapis disiplin: desain key, strategi invalidasi, dan batas data.

Kita rancang key berpola env:versi:entitas:id supaya konsisten, dapat ditebak, dan bisa dibuang berkelompok (versi key sebagai tombol panic). Kita pilih antara TTL untuk data yang boleh telat dan delete-on-write untuk kesegaran segera, selalu menulis database dulu baru menghapus cache, dan menambah jitter TTL agar key tidak kedaluwarsa berjamaah. Terakhir kita tarik garis tegas: stok, cart, status order dan payment, serta data privat tidak boleh di-cache sebagai kebenaran.

Sampai sini Redis sudah kita pakai untuk caching yang benar. Tetapi Redis bukan cuma cache. Di Chapter 4 kita memakai dua sifat khasnya, operasi atomic dan TTL alami, untuk tiga hal di luar caching: rate limiting, session dan token store, serta operasi multi-langkah yang aman.