Hệ phục vụ hàng nghìn khách hàng nên tổ chức index thế nào?

Ba mô hình, chọn theo phân bố kích thước khách hàng:

1. Index dùng chung + tenant_id filter — mặc định đúng cho phần lớn trường hợp. Ít shard, dễ vận hành. Rủi ro: lập trình viên quên filter là lộ dữ liệu chéo, nên phải ép filter ở tầng backend, không tin vào caller.
2. Index riêng cho mỗi khách hàng — cô lập tốt, xoá khách hàng chỉ là xoá index. Nhưng không scale được tới hàng nghìn: mỗi index tối thiểu một shard, mà mỗi shard tốn heap và làm cluster state phình.
3. Mô hình lai — khách hàng lớn có index riêng, số khách hàng nhỏ còn lại nằm chung một index. Đây là cách các hệ thật hay dùng.

Với mô hình 1, thêm custom routing theo tenant_id để query chỉ chạm một shard.

Một lớp bảo vệ đáng có ở tầng Elasticsearch: document level security trong role, để ngay cả khi backend quên filter thì cluster vẫn chặn.

Quyết định phải dựa trên số liệu: đếm số tenant, phân bố dung lượng, và ước lượng tổng số shard trước khi chọn.