Khi thiết kế một hệ thống web đơn giản cho cấp độ Junior, tại sao chúng ta cần sử dụng Caching và anh chị sẽ lựa chọn chiến lược Cache Aside hay Write Through trong tình huống cụ thể nào?

Question

Accepted Answer

Trong thiết kế hệ thống, Caching đóng vai trò cực kỳ quan trọng giúp giảm tải cho Database chính, tăng tốc độ phản hồi (giảm Latency) và cải thiện trải nghiệm người dùng. Đối với một lập trình viên cấp độ Junior, việc hiểu rõ các chiến lược caching cơ bản là nền tảng bắt buộc trước khi bước vào các bài toán System Design phức tạp.
1. Phân tích các chiến lược Caching phổ biến

Cache Aside (Lazy Loading):

Cơ chế hoạt động: Ứng dụng sẽ kiểm tra Cache trước tiên. Nếu dữ liệu tồn tại (Cache Hit), trả về dữ liệu ngay lập tức. Nếu không có (Cache Miss), ứng dụng sẽ truy vấn trực tiếp vào Database, lấy dữ liệu về, lưu vào Cache để phục vụ cho các lần gọi sau và cuối cùng trả về cho client.
Ưu điểm: Chỉ lưu những dữ liệu thực sự cần thiết (on-demand), tiết kiệm dung lượng bộ nhớ Cache. Nếu Cache Server bị sập, hệ thống vẫn hoạt động bình thường (chỉ chậm hơn do truy vấn trực tiếp DB).
Nhược điểm: Độ trễ (Latency) cao hơn một chút ở lần gọi đầu tiên (Cache Miss). Có nguy cơ xảy ra hiện tượng dữ liệu không đồng nhất (Cache Inconsistency) nếu dữ liệu trong DB bị thay đổi mà không cập nhật lại Cache.

Write Through:

Cơ chế hoạt động: Mỗi khi có thao tác ghi hoặc cập nhật dữ liệu, ứng dụng sẽ ghi trực tiếp vào Cache, và ngay lập tức Cache sẽ đồng bộ dữ liệu đó xuống Database.
Ưu điểm: Đảm bảo dữ liệu trong Cache luôn luôn mới và đồng nhất với Database (gần như không có độ trễ về dữ liệu cũ).
Nhược điểm: Tốn tài nguyên vì mọi dữ liệu được ghi vào dù ít hay nhiều người dùng truy cập. Thời gian ghi dữ liệu lâu hơn vì phải chờ hoàn tất cả hai quá trình ghi Cache và Database.

2. Khi nào nên lựa chọn chiến lược nào trong thực tế Enterprise?

Lựa chọn Cache Aside: 
Phù hợp với các hệ thống đọc nhiều, ghi ít (Read-heavy) như hệ thống đọc báo, trang thương mại điện tử xem danh mục sản phẩm, hoặc profile người dùng. Đây là chiến lược mặc định và an toàn nhất cho đa số các bài toán ở cấp độ Junior.

Lựa chọn Write Through:
Phù hợp với các hệ thống đòi hỏi tính chính xác tuyệt đối của dữ liệu ngay sau khi ghi và dữ liệu đó chắc chắn sẽ được đọc ngay sau đó, ví dụ như hệ thống quản lý giao dịch tài chính nhỏ hoặc cấu hình người dùng quan trọng.

3. Ví dụ minh họa mã nguồn áp dụng Cache Aside bằng Node.js
const redis = require('redis');
const client = redis.createClient();

async function getUserProfile(userId) {
    const cacheKey = `user:${userId}`;

// 1. Kiểm tra trong Cache
    const cachedData = await client.get(cacheKey);
    if (cachedData) {
        console.log('Cache Hit');
        return JSON.parse(cachedData);
    }

console.log('Cache Miss');
    // 2. Truy vấn từ Database nếu Cache Miss
    const userData = await database.query('SELECT * FROM users WHERE id = ?', [userId]);

// 3. Lưu ngược lại vào Cache với thời gian sống TTL (Time To Live)
    await client.setEx(cacheKey, 3600, JSON.stringify(userData));

return userData;
}
4. Lưu ý kinh nghiệm thực chiến

Luôn thiết lập thời gian sống (TTL - Time To Live) cho các bản ghi trong Cache để tránh tình trạng tràn bộ nhớ (Memory Leak) và tự động làm mới dữ liệu cũ.
Cần xử lý cẩn thận hiện tượng Cache Stampede (khi một key cực kỳ hot hết hạn, hàng ngàn request cùng lúc đổ dồn vào DB).

Khi thiết kế một hệ thống web đơn giản cho cấp độ Junior, tại sao chúng ta cần sử dụng Caching và anh chị sẽ lựa chọn chiến lược Cache Aside hay Write Through trong tình huống cụ thể nào?

Khóa học System Design & High Scalability

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi system design liên quan cùng chủ đề