Dashboard bắt đầu timeout trong một buổi chiều rất bình thường. Không có launch lớn, không có chiến dịch marketing, cũng không có incident lạ. Chỉ là nhiều order hơn, nhiều tenant hơn, nhiều write hơn, và nhiều report hơn mức database cũ có thể gánh thoải mái. Một người mở slow query log. Một người khác nhìn tốc độ tăng của disk. Rồi từ quen thuộc xuất hiện trong kênh architecture: sharding.
Database sharding nghĩa là chia một logical dataset ra nhiều database hoặc partition vật lý. Thay vì mọi customer, order, invoice và event đều nằm trong một nơi lớn, hệ thống quyết định shard nào sở hữu phần dữ liệu nào. Một shard có thể giữ nhóm customer theo id range. Một shard khác giữ một nhóm tenant. Một shard khác phục vụ một region. Với product, nó vẫn trông như một application. Bên dưới, dữ liệu không còn ở chung một căn phòng.
Lý do team cân nhắc sharding thường là áp lực. Một database có giới hạn: storage, write throughput, connection count, index size, backup time, replication lag và maintenance window. Vertical scaling có thể giúp một thời gian. Index tốt hơn, query sạch hơn, caching, read replica, archiving và read model denormalized cũng có thể mua thêm nhiều thời gian. Sharding đi vào cuộc trò chuyện khi những cách đơn giản hơn không còn đủ chỗ, hoặc khi business cần isolation rõ giữa tenant, region hay workload.
Lựa chọn quan trọng nhất là shard key. Một shard key tốt phân tán dữ liệu và traffic đều, giữ những query phổ biến ở trong một shard, và ít thay đổi. Một shard key tệ tạo ra hotspot. Nếu mọi record mới đều rơi vào shard theo ngày mới nhất, một shard sẽ quá tải trong khi shard khác nghỉ. Nếu product thường cần query qua nhiều customer cùng lúc, sharding theo customer id có thể làm report đắt hơn. Shard key không chỉ là chi tiết database. Nó là quyết định product và architecture dài hạn.
Sharding làm vài việc đơn giản trở nên khó hơn. Một query từng join hai bảng có thể phải hỏi nhiều shard rồi gom kết quả. Một transaction từng commit trong một database có thể cần saga, outbox, hoặc consistency model cẩn thận. Unique constraint có thể chỉ còn local thay vì global. Pagination, analytics, search và admin tool có thể cần read path riêng. Team có scale bằng cách từ bỏ sự thoải mái của một boundary mạnh.
Rebalancing là chi phí thường xuất hiện muộn hơn. Dữ liệu không tăng đều mãi. Một vài tenant lớn có thể phình nhanh hơn phần còn lại. Một region có thể tăng vượt dự đoán. Một hash range có thể cần tách. Di chuyển dữ liệu giữa các shard trong khi product vẫn chạy là việc tinh tế: dual read, dual write, backfill, verification, cutover plan và rollback path. Thiết kế sharding dễ nhất ở ngày đầu chưa chắc là thiết kế dễ vận hành ở năm thứ ba.
Observability quyết định sharding có cảm giác quản lý được hay bí ẩn. Team cần biết request đi qua shard nào, shard nào đang nóng, slow query nằm ở đâu, replication lag khác nhau thế nào, và tenant hoặc key nào tạo áp lực. Log, metric, tracing và runbook nên có thông tin shard mặc định. Nếu thiếu phần này, mỗi incident trở thành một bài đoán nơi engineer biết database đang mệt nhưng không thấy phần nào mệt.
Sharding đáng cân nhắc khi workload thật sự vượt quá một database, khi tenant isolation là yêu cầu product, hoặc khi data placement theo region quan trọng. Nó đáng được trì hoãn khi hệ thống chủ yếu đau vì query kém, thiếu index, report không giới hạn, hoặc dữ liệu đáng lẽ phải archive. Chia một database rối thành nhiều database rối hiếm khi tạo bình yên. Nó thường nhân bản sự rối đó.
Một kế hoạch sharding bình tĩnh bắt đầu trước lúc khẩn cấp. Đo áp lực hiện tại. Nhận diện access pattern. Chọn shard key theo hình dạng product. Thiết kế để sau này còn chuyển dữ liệu được. Làm rõ những workflow cross-shard. Xây dashboard và operational tool trước migration đau đầu đầu tiên. Mục tiêu không phải chứng minh hệ thống rất advanced. Mục tiêu là để tăng trưởng tiếp tục mà không biến mọi vấn đề database thành một cuộc cứu hộ ban đêm.
Lần tới khi sharding xuất hiện trong meeting, có lẽ nên xem nó như một trade-off nghiêm túc hơn là huy hiệu của scale. Một database đơn giản cho tới khi nó không còn đủ. Nhiều shard rất mạnh, nhưng chúng đòi team kỷ luật hơn. Câu hỏi hữu ích không phải sharding có hiện đại không. Câu hỏi là áp lực business đã đủ thật chưa, và team đã đủ sẵn sàng chưa, để trả chi phí đó với đôi mắt mở.