App luôn dùng chung. Câu hỏi là đặt bức tường ở đâu.The app is always shared. The question is where to put the wall.

Bức tường nằm ở đâuWhere the wall sits

Cùng hai tenant: Acme và Beta. Nét đen đậm là bức tường thật; nét đứt là bức tường chỉ tồn tại trong code của app.Same two tenants: Acme and Beta. A thick black line is a real wall; a dashed line is a wall that exists only in the app's code.

Thử làm rò rỉ dữ liệuTry to leak some data

Chọn mô hình, đăng nhập bằng một tenant, rồi bật một bug. Mỗi mô hình có đúng một kiểu lỗi chết người — và mức độ thiết kế chặn được lỗi đó cũng khác nhau.Pick a model, sign in as a tenant, then switch on a bug. Each model has one deadly mistake — and a different amount of protection against it by design.

Chọn mô hình nàoWhich model to pick

Nguyên tắc kinh nghiệm: dữ liệu càng nhạy cảm và số tenant càng ít, càng dịch về phía tách riêng (01 → 02 → 03).Rule of thumb: the more sensitive the data and the fewer the tenants, the further you move toward separation (01 → 02 → 03).

Không bắt buộc chọn một: nhiều nền tảng để phần lớn khách ở mô hình rẻ, gói cao cấp có DB hoặc instance riêng.You don't have to pick just one: many platforms keep most customers on the cheap model and sell a dedicated DB or instance as a premium tier.

Tra cứu từng mô hìnhEach model in detail

Ví dụ xuyên suốt: một app quản lý trường học phục vụ nhiều trường, mỗi trường là một tenant.Running example: a school-management app serving many schools, each school a tenant.

CREATE TABLE students (
  id        BIGSERIAL PRIMARY KEY,
  tenant_id BIGINT NOT NULL
            REFERENCES tenants(id),
  full_name TEXT NOT NULL
);
CREATE INDEX idx_students_tenant
  ON students(tenant_id);

-- Safety net: the DB enforces the filter
ALTER TABLE students
  ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON students
  USING (tenant_id =
    current_setting('app.current_tenant')::BIGINT);

acme.schoolapp.example.com → school_acme
beta.schoolapp.example.com → school_beta

-- schoolapp_control (the only shared data)
CREATE TABLE tenant_hostnames (
  hostname  TEXT PRIMARY KEY,
  tenant_id UUID NOT NULL REFERENCES tenants(id)
);

-- school_acme: no tenant_id anywhere
CREATE TABLE students (
  id        BIGSERIAL PRIMARY KEY,
  full_name TEXT NOT NULL
);
SELECT * FROM students;  -- nothing to forget

So sánh song songSide-by-side comparison

Case study

Lưới an toàn chồng lớpLayered safety nets

Ngay trong mô hình 02, app trường học không dựa vào một lớp duy nhất. Đây cũng là thứ chặn bug "control plane trả nhầm database" trong phần thử ở trên.Even within model 02, the school app doesn't rely on a single layer. These are also what stop the "control plane returns the wrong database" bug in the simulator above.

• 1Mỗi tenant một databaseA database per tenantKhông có bảng dùng chung để rò rỉ.No shared tables to leak from.
• 2Tra tenant trước tiênTenant lookup firstApp tra địa chỉ web → tenant trước mọi thứ khác trong request.Web address → tenant is resolved before anything else in the request.
• 3Khoá đăng nhập riêngPer-tenant login keysToken của Acme không dùng được cho Beta.An Acme token won't work for Beta.
• 4Quyền databaseDatabase permissionsUser DB của mỗi tenant chỉ chạm được database của chính nó, kể cả khi app bị chiếm quyền.Each tenant's DB user can only touch its own database, even if the app is compromised.

Sai lầm hay gặpCommon mistakes

Ba câu cần nhớThree things to remember

• Multi-tenancy luôn là nhiều công ty dùng chung một app; các mô hình chỉ khác nhau ở cách tách dữ liệu.Multi-tenancy is always many companies sharing one app; the models differ only in how the data is separated.
• DB dùng chung + tenant_id là mô hình 01 — hợp lệ, nhưng không phải dạng duy nhất, và cô lập chỉ chắc bằng code của bạn.Shared DB + tenant_id is model 01 — valid, but not the only form, and its isolation is only as solid as your code.
• Đánh đổi luôn là chi phí đổi lấy mức cô lập: dùng chung thì rẻ hơn, tách riêng thì an toàn hơn.The trade-off is always cost versus isolation: shared is cheaper, separated is safer.