Phần 7: Cache strategy: invalidation là bài toán khó nhất

import "golang.org/x/sync/singleflight"

var group singleflight.Group

func GetProduct(ctx context.Context, id string) (*Product, error) {
    key := "product:" + id

```text
// Kiểm tra cache trước
cached, err := redis.Get(ctx, key).Result()
if err == nil {
    return deserialize(cached)
}

// Singleflight: chỉ 1 request đi DB, các request khác chờ
v, err, _ := group.Do(key, func() (interface{}, error) {
    product, err := db.GetProduct(ctx, id)
    if err != nil {
        return nil, err
    }
    redis.Set(ctx, key, serialize(product), 5*time.Minute)
    return product, nil
})
if err != nil {
    return nil, err
}
return v.(*Product), nil

```text
}

```text
Pattern Go ở trên dùng `singleflight.Group`, chỉ request đầu tiên thực sự gọi DB, các request khác cùng key chờ kết quả. Trong Node.js, pattern tương tự là dùng Promise dedup, lưu Promise đang pending cho mỗi key, request mới await Promise đó thay vì tạo Promise mới.

### Probabilistic early expiration

Thay vì chờ TTL hết rồi mới miss, mỗi request khi đọc cache sẽ tính xác suất "expire sớm" dựa trên thời gian còn lại của TTL. Khi TTL gần hết, xác suất tăng, một request may mắn sẽ trigger refresh cache **trước khi key hết hạn**, trong khi các request khác vẫn đọc cache cũ bình thường.

Thuật toán XFetch là ví dụ điển hình: `shouldRefresh = (currentTime - fetchTime) > TTL * β * log(random())` với β thường chọn khoảng 1.0. Khi thời gian gần hết TTL, xác suất shouldRefresh tăng dần, đảm bảo cache được refresh trước khi expire thật.

Ưu điểm là không cần lock, không cần coordination, mỗi instance tự quyết định có refresh không. Nhược điểm là vẫn có thể có 2-3 request trùng refresh cùng lúc (xác suất thấp nhưng không bằng 0), và logic phức tạp hơn TTL thuần.

### Background refresh

Cách tiếp cận khác: cache entry có TTL dài (hoặc không expire), nhưng một background job định kỳ refresh data từ DB vào cache. Client luôn đọc từ cache, không bao giờ miss, cache luôn nóng, không có stampede.

Phù hợp cho data thay đổi ít nhưng đọc rất nhiều, ví dụ product catalog, site config, exchange rate. Không phù hợp cho data per-user vì số key quá lớn để refresh toàn bộ.

Nhược điểm: stale window bằng khoảng cách giữa hai lần refresh. Và nếu background job fail, cache có thể chứa data cũ rất lâu, cần monitoring job health.

---

## Cache warming, khởi động nóng

Cold start là lúc cache trống rỗng, sau deploy mới, sau cache flush, hoặc khi scale thêm instance. Mọi request đều miss cache, DB nhận toàn bộ traffic. Nếu hệ thống đã depend vào cache cho performance (và hầu hết hệ thống có cache đều vậy), cold start có thể là mini-outage.

Cache warming là pre-populate cache trước khi traffic đến. Cách đơn giản nhất: chạy script đọc top N key phổ biến nhất từ DB và ghi vào cache. Có thể dựa trên access log phân tích key nào được query nhiều nhất, hoặc đơn giản là warm toàn bộ bảng nếu data nhỏ.

Một pattern mình thấy hiệu quả: khi deploy instance mới, instance đó nhận traffic dần dần (canary hoặc weight-based routing). Traffic ít ban đầu gây cache miss ở tốc độ DB chịu được, cache nóng dần, rồi mới nhận full traffic. Kubernetes rolling update tự nhiên có hành vi tương tự, pod mới nhận traffic từ từ khi readiness probe pass.

Cẩn thận với cache warming quá aggressive, warm 10 triệu key cùng lúc có thể gây spike load lên DB tương tự stampede. Warm dần dần, throttle write, hoặc warm từ replica DB thay vì primary.

---

## Multi-level cache, L1 và L2

Một lớp cache Redis đã nhanh, latency khoảng 0.5-1ms qua network. Nhưng khi cần nhanh hơn nữa, hoặc khi Redis trở thành bottleneck (throughput hoặc bandwidth), thêm cache cấp hai: in-process cache (L1) ngay trong memory của application.

L1 là cache nằm trong process, Caffeine (Java), lru-cache (Node.js), groupcache (Go). Latency gần bằng 0 (memory access, không qua network). Nhưng capacity nhỏ (bị giới hạn bởi heap size), và mỗi instance có L1 riêng, không chia sẻ giữa instances.

L2 là cache distributed, Redis, Memcached. Capacity lớn hơn nhiều, chia sẻ giữa mọi instance. Nhưng có network latency.

Flow: app đọc L1 trước. L1 miss → đọc L2 (Redis). L2 miss → đọc DB, ghi L2, ghi L1. Khi data thay đổi: invalidate L2 (xoá key Redis), nhưng **L1 trên các instance khác vẫn chứa data cũ**, đây là bài toán consistency giữa hai lớp cache.

Giải pháp phổ biến: L1 có TTL rất ngắn (vài giây đến vài chục giây) để tự hết hạn nhanh. Hoặc dùng Redis Pub/Sub để broadcast invalidation event, khi một instance invalidate L2, nó publish message, các instance khác nhận message và xoá L1 local. Pattern thứ hai cho consistency tốt hơn nhưng phức tạp hơn.

Multi-level cache hữu ích khi read QPS rất cao (hàng chục nghìn trở lên) và data thay đổi chậm. Với hầu hết ứng dụng, chỉ L2 Redis là đủ, thêm L1 khi profiling cho thấy Redis latency là bottleneck thực sự, không phải thêm vì "nghe hay".

---

## Cache key design

Cache key tưởng đơn giản, `product:42`, nhưng key design tệ gây collision, gây khó debug, và gây khó invalidation hàng loạt.

Namespace prefix là bắt buộc. `product:42` có thể collision với key của service khác dùng chung Redis. Dùng `order-svc:product:42` hoặc `v1:product:42` để tránh. Prefix theo version (`v1:`, `v2:`) cho phép invalidate toàn bộ cache khi schema thay đổi, deploy version mới dùng prefix `v2:`, toàn bộ key `v1:` tự hết hạn theo TTL.

Key phải **deterministic**, cùng input luôn sinh cùng key. Nếu key chứa query parameter, phải sort parameter trước khi hash: `?page=1&sort=name` và `?sort=name&page=1` phải sinh cùng key. Quên sort là tạo hai cache entry cho cùng data, tốn memory và invalidation phải xoá cả hai.

Tránh key quá dài, Redis key tốn memory, key 500 bytes cho hàng triệu entry là đáng kể. Nhưng cũng tránh key quá ngắn đến mức không debug được, `p:42` không ai hiểu khi grep Redis. Cân bằng hợp lý: `svc:product:42` là đủ rõ.

Với cache cho query phức tạp (filter, sort, pagination), hash toàn bộ query parameter thành digest ngắn: `svc:products:list:sha256(sortBy=name&category=phone&page=2)`. Nhưng cẩn thận: invalidation trở nên khó vì bạn không biết tất cả key nào chứa product 42 khi product 42 thay đổi. Đây là lý do nhiều team chọn **invalidate theo prefix** (xoá tất cả key `svc:products:list:*`) thay vì per-key, đơn giản hơn dù tốn cache miss nhiều hơn.

---

## Redis vs Memcached

Hai engine cache phổ biến nhất, và câu hỏi "nên dùng cái nào" xuất hiện trong mọi design review.

Memcached đơn giản, chỉ hỗ trợ key-value string, không có data structure phức tạp. Multi-threaded by design nên tận dụng nhiều core tốt. Không có persistence, restart là mất hết data. Phù hợp khi bạn chỉ cần cache thuần, không cần data structure, và chấp nhận cold start sau restart.

Redis mạnh hơn nhiều, hỗ trợ hash, list, set, sorted set, stream, pub/sub. Có persistence (RDB snapshot + AOF log) nên restart không mất data hoàn toàn. Hỗ trợ Lua scripting cho atomic operation phức tạp. Clustering với Redis Cluster cho horizontal scaling. Pub/Sub cho event broadcasting (dùng cho cache invalidation giữa instances).

Trong thực tế, Redis thắng áp đảo cho hầu hết use case vì versatility, bạn dùng Redis cho cache, cho session store, cho rate limiter, cho pub/sub, cho queue nhẹ (nói thật: 80% case chọn Redis vì nó đã có sẵn trong stack, không phải vì đã ngồi benchmark kỹ với Memcached). Memcached chỉ hợp khi bạn cần cache thuần với throughput cực cao và không cần bất kỳ feature nào khác.

Một điểm ít người để ý: Redis single-threaded cho command execution (từ v6 có IO threading nhưng command vẫn single-threaded). Với workload mà mỗi command nhanh (GET/SET key nhỏ), Redis đạt hàng trăm nghìn ops/giây trên một instance, đủ cho phần lớn ứng dụng. Nhưng nếu bạn chạy command chậm (KEYS *, SORT trên set lớn, Lua script dài), nó block toàn bộ instance. Tuyệt đối không chạy `KEYS *` trên production Redis, dùng `SCAN` thay thế.

---

## Eviction policies, khi cache đầy

Cache có capacity hữu hạn. Khi memory full, Redis cần quyết định xoá key nào để nhường chỗ cho key mới. Eviction policy quyết định key nào bị "hi sinh".

**LRU (Least Recently Used)** xoá key ít được truy cập gần đây nhất. Logic: nếu lâu rồi không ai đọc thì chắc không cần nữa. Redis implement approximated LRU (sample N key random, xoá key có last access cũ nhất trong sample) thay vì exact LRU, tiết kiệm memory cho metadata. LRU là policy mặc định hợp lý cho hầu hết use case.

**LFU (Least Frequently Used)** xoá key ít được truy cập nhất (tính theo tổng số lần). Khác LRU ở chỗ: key được truy cập rất nhiều trong quá khứ nhưng gần đây không ai dùng vẫn được giữ (LRU sẽ xoá). LFU tốt hơn LRU khi access pattern có "popular items" rõ ràng, top 100 product được xem liên tục, còn lại long tail. Redis 4.0+ hỗ trợ LFU.

**TTL-based eviction** (`volatile-ttl`) ưu tiên xoá key có TTL sắp hết, hợp lý vì key sắp hết hạn anyway. Chỉ áp dụng cho key có TTL; key không set TTL không bao giờ bị evict. Cẩn thận: nếu bạn có key quan trọng không set TTL và policy là `volatile-*`, những key đó sẽ tồn tại mãi, có thể chiếm hết memory.

**allkeys-random** xoá key random, đơn giản, unpredictable, hiếm khi là lựa chọn tốt trừ khi access pattern hoàn toàn uniform.

**noeviction**, Redis từ chối write mới khi memory full. Application nhận lỗi. Phù hợp khi bạn dùng Redis như data store (không chỉ cache) và không muốn mất data bất ngờ.

Khuyến nghị: dùng `allkeys-lru` hoặc `allkeys-lfu` cho cache use case. Monitor `evicted_keys` metric, nếu eviction rate cao liên tục, cache đang thiếu memory, cần scale up hoặc review xem có key nào không cần cache.

---

## Anti-pattern phổ biến

### Cache everything

Không phải data nào cũng nên cache. Data thay đổi liên tục (inventory count realtime, stock price) cache xong bị invalidate ngay, tốn effort mà không giảm tải DB đáng kể. Data ít khi đọc (audit log, report cũ) cache là phí memory. Chỉ cache data **đọc nhiều, thay đổi ít**, sweet spot của caching.

### Không set TTL

Mọi cache entry phải có TTL. Key không có TTL tồn tại vĩnh viễn (hoặc cho đến khi bị evict), nếu invalidation logic có bug, data cũ sống mãi. TTL là safety net cuối cùng chống stale data. Dù đã có event-based invalidation, vẫn set TTL, defense in depth.

### Cache as primary data store

Cache là bản sao, không phải nguồn sự thật. Nếu bạn ghi vào Redis mà không ghi DB, và Redis crash, data mất. Mình từng thấy team lưu shopping cart chỉ trong Redis, user add item, Redis chết, cart trống, user tức giận. Shopping cart là data có giá trị, lưu DB, cache Redis cho performance.

### Ignoring cold start

Deploy service mới, cache trống, 100% request đi DB, DB overload, cascade failure. Đã có team phải rollback deploy chỉ vì cold cache gây DB spike. Plan cache warming hoặc gradual traffic ramp-up trước khi nhận full load.

### Cache key không có namespace

Hai service cùng dùng Redis cluster, cùng dùng key `user:42`, service A ghi profile, service B đọc ra nhận session data. Collision thầm lặng, bug khó tìm vì data "có" nhưng sai format. Namespace mọi key bằng service name hoặc domain prefix.

---

## Monitoring cache, những con số cần theo dõi

Cache không phải setup xong rồi quên. Một số metric cần trên dashboard và có alert đi kèm.

**Hit rate** là metric quan trọng nhất, tỷ lệ request được phục vụ từ cache. Hit rate 95% nghĩa là chỉ 5% request đi DB. Hit rate giảm đột ngột là dấu hiệu có vấn đề: TTL quá ngắn, cache bị flush, hoặc access pattern thay đổi. Hit rate dưới 80% cho cache-aside thì cần xem lại cache strategy, có thể data không phù hợp để cache.

**Miss rate** tương ứng ngược với hit rate. Miss rate tăng spike thường correlate với DB latency tăng, vì mỗi miss là một DB query.

**Eviction rate**, số key bị evict mỗi giây vì memory full. Eviction rate cao liên tục nghĩa là cache thiếu memory, key vừa populate xong đã bị evict nhường chỗ, hit rate giảm. Scale up Redis memory hoặc review key nào chiếm nhiều space nhất.

**Memory usage**, bao nhiêu phần trăm maxmemory đã dùng. Đặt alert ở 80% để có thời gian scale trước khi đầy.

**Latency**, Redis command latency. Bình thường dưới 1ms cho GET/SET key nhỏ. Nếu latency tăng, kiểm tra slow log (`SLOWLOG GET`), kiểm tra key lớn (`DEBUG OBJECT key`), kiểm tra network giữa app và Redis.

**Connection count**, số connection đang active. Redis single-threaded nên nhiều connection không giúp performance, nhưng quá nhiều connection idle tốn memory. Dùng connection pooling với size hợp lý (thường 10-50 per instance tuỳ workload).

```bash
# Redis CLI: kiểm tra nhanh cache health
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses|evicted_keys"
redis-cli INFO memory | grep used_memory_human
redis-cli SLOWLOG GET 10

```text
Metric này nên được scrape bởi Prometheus (dùng redis-exporter) và hiển thị trên Grafana. Đặt alert cho hit rate giảm quá ngưỡng, eviction rate spike, và latency P99 tăng bất thường.

---

Cache không phải bữa ăn miễn phí, mọi cache entry cần TTL, mọi invalidation cần ít nhất hai lớp phòng thủ (event-based + TTL làm safety net). Bài toán thực sự không phải là cache nhanh như thế nào, mà là khi nào data cũ gây hại đủ để người dùng mất niềm tin, câu trả lời đó quyết định toàn bộ chiến lược.