Đây là bài 2 trong phần 4 của chuỗi demo “System Design: Giải thích những quyết định kiến trúc”. Đặt giả định, chọn ranh giới và đánh giá tradeoff khi thiết kế một nền tảng học trực tuyến. Bài viết dùng ví dụ và dữ liệu giả để minh họa; hãy thử trên môi trường riêng trước khi áp dụng vào dự án.
Mục tiêu cụ thể
Cache giảm việc đọc lại dữ liệu chậm nhưng tạo một bản sao có thể cũ. Chọn TTL và cách xóa cache dựa trên mức độ chấp nhận dữ liệu cũ của từng tác vụ.
Tình huống lỗi
Cache key thiếu user hoặc tenant có thể trả nhầm dữ liệu. Xóa cache sau cập nhật vẫn có thể gặp race nếu request khác ghi lại bản cũ.
Chẩn đoán có bằng chứng
Trong bài cache và tính nhất quán, hãy cố ý tái hiện tình huống trên ở môi trường thử nghiệm. Mục tiêu là thấy vì sao kết quả sai và thu thập đủ bằng chứng để phân biệt lỗi dữ liệu, lỗi quy tắc và lỗi cấu hình. Không sửa đồng thời nhiều yếu tố vì bạn sẽ khó xác định nguyên nhân.
- Ghi rõ bước thao tác và kết quả mong đợi.
- Thu nhỏ ví dụ đến mức vẫn tái hiện được lỗi.
- Đối chiếu dữ liệu thực với giả định ban đầu.
- Đặt giả thuyết và thay đổi một yếu tố.
- Xác nhận bằng cách tái chạy ví dụ tối thiểu.
Mẫu đối chiếu
catalog:page:1 -> danh sách public, TTL ngắn
course:42:v3 -> mô tả khóa học theo phiên bản
Quyền xem bài: kiểm tra từ nguồn quyền đáng tin cậy
Không dùng cache công khai chung cho dữ liệu cá nhân.Kiểm tra sau sửa
- Key chứa đủ ngữ cảnh
- Dữ liệu riêng không dùng cache chung
- Mô tả cách xử lý dữ liệu cũ
Khi lỗi biến mất, thực hiện lại yêu cầu gốc: Đề xuất cache cho danh mục nhưng tách kiểm tra quyền xem video; phân tích một race condition. Sau đó thử trường hợp đầu vào rỗng hoặc trạng thái chưa được khởi tạo nếu phù hợp. Một bản sửa phải khôi phục hành vi đã định nghĩa, không chỉ làm mất thông báo lỗi.
Ghi chú bàn giao
Viết báo cáo ngắn gồm nguyên nhân, phạm vi ảnh hưởng, thay đổi và cách kiểm chứng. Nếu chưa xác định được nguyên nhân, ghi rõ điều còn chưa biết và phép kiểm tra tiếp theo, không biến giả thuyết thành kết luận.