Kiến trúc Multi-tenant và database

I. Tổng quan về Multi-tenant

Multi-tenant (đa thuê bao) là mô hình kiến trúc trong đó một phiên bản phần mềm duy nhất phục vụ nhiều khách hàng (tenant). Mỗi tenant có thể là một công ty, người dùng, tổ chức… và có dữ liệu riêng biệt, nhưng vẫn dùng chung tài nguyên phần mềm hoặc hạ tầng.

Ví dụ: Google Workspace, Slack, hoặc bất kỳ hệ thống SaaS (Multi-tenant Software as a Service) nào cũng đều là dạng multi-tenant.

II. Lợi ích của Multi-tenant

Lợi ích	Mô tả
Tối ưu tài nguyên	Một hệ thống duy nhất phục vụ nhiều tenant → giảm chi phí vận hành.
Dễ mở rộng	Có thể onboard tenant mới nhanh chóng.
Quản lý tập trung	Update, bảo mật, giám sát trên cùng 1 nền tảng.
Kinh tế hơn	Chi phí lưu trữ và bảo trì thấp hơn so với single-tenant.

III.Các mô hình kiến trúc database trong multi-tenant

1. Shared Database – Shared Schema

Mô tả:

Tất cả tenant dùng chung một database và một schema. Dữ liệu được phân biệt bằng cột tenant_id.

Ví dụ:

SELECT * FROM orders WHERE tenant_id = ‘company_a’;

Ưu điểm:

Dễ quản lý.
Chi phí thấp.
Triển khai nhanh.

Nhược điểm:

Bảo mật dữ liệu giữa tenants phụ thuộc 100% vào ứng dụng.
Khó backup/restore riêng lẻ.
Scale khó khi tenant tăng quá nhiều.

2. Shared Database – Isolated Schema

Mô tả:

Tất cả tenant dùng chung 1 database, nhưng mỗi tenant có 1 schema riêng biệt.

Ví dụ:

Schema company_a.orders, company_b.orders, …

Ưu điểm:

Dữ liệu tách biệt hơn, dễ backup theo schema.
Dễ mở rộng cấu trúc dữ liệu tùy biến cho từng tenant.

Nhược điểm:

Quản lý phức tạp nếu số lượng schema tăng nhiều.
Không phải hệ quản trị CSDL nào cũng hỗ trợ schema tốt (MySQL hỗ trợ kém hơn PostgreSQL).

3. Isolated Database – mỗi tenant 1 database riêng

Mô tả:

Mỗi tenant có 1 database độc lập. Ứng dụng sẽ switch kết nối tùy theo tenant.

Ưu điểm:

Bảo mật cao nhất (tenant này không bao giờ truy cập nhầm dữ liệu tenant khác).
Dễ dàng scale, migrate, backup theo tenant. Tính linh hoạt cao, bạn thử hình dung 1 tenant cần mã hoá dữ liệu nhưng các tenant khác không cần.
Tùy biến cấu trúc dữ liệu mỗi tenant.

Nhược điểm:

Phức tạp hơn về DevOps (Development & Operations): phải quản lý nhiều kết nối, backup, migration…
Chi phí lưu trữ cao hơn.
Đòi hỏi viết code linh hoạt hơn.

IV. Khi nào thì nên chọn kiến trúc nào?

Tiêu chí	Shared Schema	Isolated Schema	Isolated Database
Số lượng tenants	Hàng trăm – hàng triệu	Vài chục – vài trăm	Dưới 1000
Tùy biến dữ liệu theo tenant	Không	Có thể	Có thể
Tách biệt dữ liệu	Thấp	Trung bình	Rất cao
Bảo trì	Dễ	Trung bình	Khó hơn
Bảo mật	Dựa vào ứng dụng	Khá tốt	Rất tốt

V. Những vấn đề cần lưu ý trong multi-tenant

1. Authentication & Authorization

Cần kiểm tra tenant_id mọi nơi.
Đảm bảo middleware hoặc filter kiểm soát quyền truy cập đúng.

2. Data Isolation

Ở mô hình Shared Schema, cần cơ chế Row-Level Security (nếu dùng PostgreSQL) hoặc query wrapping.

3. Migration

Với Isolated DB, mỗi tenant cần chạy migration riêng (nên dùng tool như Flyway, Liquibase).

4. Performance

Dễ bị “noisy neighbor” (1 tenant load cao làm ảnh hưởng toàn hệ thống) nếu không có phân vùng/tối ưu tốt.

5. Monitoring

Cần tracking theo tenant: lỗi, tốc độ, số lượng request, dung lượng DB…

VI. Thực tế: SaaS thường chọn gì?

Startup nhỏ → Shared DB + Shared Schema.
Hệ thống cần bảo mật cao (ngân hàng, B2B lớn) → Isolated DB.
Các nền tảng SaaS quy mô trung bình → Shared DB + Isolated Schema để dễ mở rộng và quản lý.