Caching Strategies: Không chỉ là 'Bỏ vào Redis'

“Tại sao API chậm thế? Thêm Redis vào đi!”

Tôi cá là bạn đã nghe câu này ít nhất 10 lần trong sự nghiệp. Nhưng “Thêm Redis” không đơn giản là Cache::put().

Chọn sai chiến lược caching không chỉ không làm nhanh hệ thống, mà còn sinh ra những bug “ma quỷ” về tính nhất quán dữ liệu (Data Consistency) mà debug cả tuần không ra.

Hôm nay chúng ta bàn về 3 chiến lược cốt lõi.

1. Cache-Aside (Lazy Loading) - “Chuẩn cơm mẹ nấu”

Đây là cách 90% chúng ta đang làm.

1. App check Cache.
2. Nếu có (Hit) -> Trả về data.
3. Nếu không (Miss) -> Query Database -> Trả về data -> Lưu vào Cache.

Ưu điểm:

• Dữ liệu trong cache luôn là dữ liệu “được cần đến” (Lazy).
• Nếu Cache sập, App vẫn chạy (chỉ chậm hơn vì chọc thẳng DB).

Nhược điểm:

• Stale Data: Nếu DB được update ở chỗ khác mà không xóa Cache, user sẽ thấy dữ liệu cũ.
• Thundering Herd: Nếu key hot hết hạn, DB có thể sập vì nghẽn cổ chai.

2. Write-Through - “Vừa đấm vừa xoa”

Khi update dữ liệu:

1. App ghi vào Cache.
2. App ghi vào Database (đồng bộ).
3. Cả 2 thành công mới trả về OK.

Ưu điểm:

• Data consistency cực cao. Cache và DB luôn giống nhau.
• Read performance rất tốt vì dữ liệu luôn sẵn sàng.

Nhược điểm:

• Write latency cao (phải chờ cả 2 thằng ghi xong).

3. Write-Behind (Write-Back) - “Liều ăn nhiều”

Khi update dữ liệu:

1. App ghi vào Cache -> Trả về OK ngay lập tức.
2. Bên dưới (Async), Cache system từ từ đồng bộ dữ liệu vào Database.

Ưu điểm:

• Write performance siêu khủng (tốc độ RAM).
• Giảm tải cực lớn cho Database (Batch update).

Nhược điểm:

• Rủi ro cao: Nếu Cache server sập trước khi kịp sync vào DB -> Mất dữ liệu vĩnh viễn.
• Chỉ nên dùng cho dữ liệu không quan trọng (lượt view, like) hoặc nếu bạn có hệ thống backup cache cực xịn.

Case Study: Shopee Flash Sale

Trong các đợt Flash Sale, Shopee không thể dùng Cache-Aside cho Inventory (kho hàng) vì latency query DB quá lớn. Họ thường dùng kết hợp Redis (Write-through) để decrement stock, sau đó dùng Queue để update vào DB sau.

Kết luận

Đừng cache mù quáng.

• Cần nhất quán? Write-through.
• Cần tốc độ ghi tối đa và chấp nhận rủi ro? Write-behind.
• Cần an toàn và đơn giản? Cache-aside.

Và nhớ câu thần chú: “There are only two hard things in Computer Science: cache invalidation and naming things.”