Ranh giới multi-tenant — chọn mô hình trước khi scale
Shared schema, schema-per-tenant, hay DB-per-tenant? Viết rõ mô hình tenancy trước khi compliance và support kéo bạn vào cuộc.
Mười khách đầu, một schema chung — “cho nhanh”. Ổn. Đến khách thứ hai mươi, email support: “Sao export của tôi có dữ liệu tenant khác?”
Đó không phải bug query lẻ tẻ. Đó là chưa chọn ranh giới tenancy — hoặc chọn rồi nhưng enforce bằng thói quen SQL thay vì kiến trúc.
Viết được một câu về tenancy
Trước khi tối ưu query, hãy trả lời được:
- Dữ liệu khách A lẫn vào khách B bằng cách nào?
- Service nào bắt buộc gắn tenant context?
- Tách một khách “ồn ào” — đường thoát là gì?
Không viết được → chưa có mô hình, chỉ có thói quen copy-paste filter.
Ba hướng, ba cái giá
- Shared DB + cột tenant — rẻ, blast radius lớn.
- Schema-per-tenant — tách rõ hơn, migration nặng hơn.
- DB-per-tenant — cách ly mạnh, ops đắt.
Không có đáp án “đúng tuyệt đối”. Có đáp án bạn giải thích được với support và compliance trên cuộc gọi — không phải trên slide.
Enforce ở mép domain
Tenant context thuộc middleware / gateway — không phải filter tùy chọn trong từng repository.
Filter tùy chọn sẽ bị quên. Quên một lần là một incident. Incident thành slide “rewrite platform” — đắt hơn middleware một dòng.
Takeaway
Tenancy là ranh giới sản phẩm, không phải chi tiết ORM. Chọn mô hình sớm, enforce cứng, giữ lối thoát khi một khách cần cô lập.
Schema lúc mười khách là câu chuyện bạn kể lúc một trăm — trừ khi đã drill export/restore từ trước.
Found this insightful? Like or share with your team:
Spread good engineering craft & architecture lessons.
Comments
Email is not published. Keep it professional.