System DesignBước này chốt ba việc: thực thể chính, kiểu lưu trữ, và khóa truy cập.
1. Thực thể và quan hệ. Liệt kê 3-5 bảng cốt lõi với các cột quan trọng, không cần đủ. Với bài news feed: users, posts, follows, feed_items.
2. Chọn kiểu lưu trữ theo mẫu truy vấn, không theo sở thích.
- Truy vấn liên bảng nhiều, cần giao dịch nhiều bảng, ràng buộc toàn vẹn → quan hệ (PostgreSQL, MySQL).
- Mẫu truy vấn cố định theo một khóa, ghi rất nhiều, cần scale ngang tự nhiên → key-value hoặc wide-column (DynamoDB, Cassandra).
- Tìm kiếm toàn văn, xếp hạng → công cụ tìm kiếm riêng (Elasticsearch), đồng bộ từ nguồn chính.
- Dữ liệu nóng, đọc lặp lại → cache trong RAM đặt trước store chính.
3. Khóa chính và khóa phân mảnh. Đây là điểm hay bị bỏ sót. Khóa phân mảnh quyết định dữ liệu phân bố ra sao. Chọn khóa có lực phân tán cao và gắn với mẫu truy vấn: phân mảnh feed theo user_id cho phép lấy toàn bộ feed của một người trong một phân mảnh. Tránh khóa tăng dần theo thời gian làm khóa phân mảnh — mọi ghi mới dồn vào một phân mảnh, tạo điểm nóng.
4. Chỉ mục. Nêu 1-2 chỉ mục phục vụ truy vấn chính, ví dụ (user_id, created_at DESC) cho truy vấn lấy bài mới nhất của một người.
Cuối bước, nói rõ chỗ nào chấp nhận denormalize để đổi lấy tốc độ đọc, và cái giá phải trả là ghi nhiều nơi cùng lúc.