System DesignShard key quyết định dữ liệu nằm ở đâu, và một khi đã có dữ liệu thật thì rất khó đổi. Bốn tiêu chí:
1. Phân bố đều — cardinality cao, không dồn cục. Ngày tháng làm shard key khiến toàn bộ ghi hôm nay đổ vào một shard.
2. Khớp truy vấn chính — key phải nằm trong hầu hết mệnh đề WHERE. Nếu không, mọi truy vấn thành scatter-gather: hỏi tất cả shard rồi gộp, latency bằng shard chậm nhất.
3. Gom được dữ liệu cần đọc cùng nhau — dữ liệu của một tenant/user nên nằm chung shard để tránh join và transaction xuyên shard.
4. Ổn định — giá trị key không được thay đổi, vì đổi key nghĩa là chuyển bản ghi sang shard khác.
Ví dụ hệ multi-tenant: tenant_id gom đúng truy vấn nhưng lệch nặng khi có tenant khổng lồ; hash(user_id) phân bố đều nhưng báo cáo theo tenant phải quét mọi shard. Thực tế hay dùng key ghép và tách riêng tenant lớn.
Khi phải resharding, không có đường tắt an toàn:
- Dùng consistent hashing hoặc nhiều shard logic ánh xạ vào ít shard vật lý ngay từ đầu — khi tách chỉ cần chuyển một phần shard logic sang máy mới, không phải xáo trộn toàn bộ.
- Quy trình chuyển sống: dual-write vào cả layout cũ và mới, backfill dữ liệu cũ, đối soát, chuyển đọc dần theo phần trăm, chỉ khi ổn mới bỏ layout cũ. Luôn giữ đường quay lui.
Trước khi sharding, kiểm tra đã dùng hết cách rẻ hơn chưa: index đúng, đọc từ replica, cache, archive dữ liệu cũ, partition trong cùng một instance.