Multi-tenant SaaS là gì? Kiến trúc đa người dùng phục vụ hàng nghìn doanh nghiệp
Multi-tenant SaaS cho phép một nền tảng phục vụ hàng nghìn doanh nghiệp với dữ liệu cô lập an toàn. Phân tích kiến trúc, cách ly dữ liệu nhiều lớp và tuỳ biến theo từng khách hàng — dễ hiểu cho cả người kinh doanh lẫn kỹ thuật.
Founder, NKKTech Group · CEO, est-invoice
Khi một doanh nghiệp đăng ký dùng một phần mềm như Slack, Salesforce hay một nền tảng hoá đơn điện tử, họ thường nghĩ mình đang dùng phần mềm riêng của mình. Nhưng phía sau, hàng nghìn doanh nghiệp khác cũng đang chạy trên cùng một hệ thống — mà không ai nhìn thấy dữ liệu của ai. Đó chính là multi-tenant (đa người thuê) — kiến trúc nền tảng của hầu hết phần mềm SaaS hiện đại.
Bài viết này giải thích multi-tenant theo cách dễ hiểu cho cả người làm kinh doanh lẫn người làm kỹ thuật: nó là gì, vì sao quan trọng, cách ly dữ liệu ra sao, và những cạm bẫy cần tránh khi xây dựng.
Multi-tenant vs single-tenant: khác nhau ở đâu?
- Single-tenant giống như mỗi khách hàng có một căn nhà riêng: một bản cài đặt, một cơ sở dữ liệu, một máy chủ riêng. An toàn tuyệt đối về cách ly, nhưng tốn kém.
- Multi-tenant giống như một toà chung cư cao cấp: mọi người dùng chung hạ tầng, nhưng mỗi căn hộ có khoá riêng và không ai vào được nhà người khác. Một bản phần mềm phục vụ tất cả, chi phí chia sẻ, cập nhật một lần áp dụng cho mọi người.
Gần như mọi SaaS thành công ngày nay chọn multi-tenant, vì nó là cách duy nhất để phục vụ hàng nghìn khách hàng với chi phí hợp lý và tốc độ phát triển nhanh.
"Tenant" là gì và cách ly dữ liệu hoạt động ra sao?
Tenant là một đơn vị khách hàng — thường là một doanh nghiệp, cùng toàn bộ người dùng và dữ liệu thuộc về nó. Trái tim của multi-tenant là câu hỏi: làm sao đảm bảo tenant A không bao giờ nhìn thấy dữ liệu của tenant B? Có ba cấp độ cách ly phổ biến:
1. Cách ly theo dòng dữ liệu (shared database, shared schema)
Tất cả tenant dùng chung bảng dữ liệu, mỗi bản ghi gắn một cột tenant_id. Mọi truy vấn bắt buộc lọc theo tenant_id. Đây là mô hình tiết kiệm nhất — nhưng cũng nguy hiểm nhất nếu lập trình ẩu: chỉ cần một truy vấn quên điều kiện tenant_id là dữ liệu rò rỉ chéo.
2. Cách ly theo schema (shared database, separate schema)
Mỗi tenant có một không gian bảng riêng trong cùng một cơ sở dữ liệu. Cân bằng tốt giữa cách ly và chi phí.
3. Cách ly theo cơ sở dữ liệu (separate database)
Mỗi tenant một database riêng. Gần với single-tenant về độ an toàn, thường dùng cho khách hàng lớn yêu cầu cao về tuân thủ. Nhiều nền tảng trưởng thành áp dụng mô hình lai: khách nhỏ dùng chung database với tenant_id, khách lớn được tách riêng database khi cần.
Phòng tuyến bảo mật: không bao giờ chỉ dựa vào một lớp
Bài học xương máu của mọi đội xây SaaS: cách ly dữ liệu phải được thực thi ở nhiều tầng, không phó mặc cho lập trình viên nhớ thêm điều kiện tenant mỗi lần viết truy vấn.
- Tầng ứng dụng: mọi truy vấn đi qua một lớp trung gian tự động chèn điều kiện tenant — lập trình viên không thể quên.
- Tầng cơ sở dữ liệu (RLS — Row-Level Security): database tự từ chối trả về bản ghi không thuộc tenant hiện tại, kể cả khi truy vấn sai.
- Tầng kiểm thử tự động: test chuyên biệt cố tình truy cập chéo tenant và phải thất bại — nếu nó thành công, build bị chặn.
- Tầng phân quyền (RBAC): mỗi người dùng chỉ thấy đúng phần dữ liệu trong tenant của họ.
Tuỳ biến theo từng tenant mà không phân mảnh sản phẩm
Nếu mọi tenant dùng chung một bản phần mềm, làm sao đáp ứng nhu cầu riêng của từng khách hàng (logo riêng, quy trình riêng, bảng giá riêng)? Lời giải là feature flags (cờ tính năng) và cấu hình theo tenant:
- Mỗi tenant có một bộ cấu hình riêng (thương hiệu, ngôn ngữ, công thức tính giá, quy trình duyệt).
- Tính năng đặc thù được bật/tắt bằng cờ, thay vì tách nhánh mã nguồn riêng cho từng khách hàng.
- Nhờ đó, một codebase duy nhất phục vụ mọi tenant — cập nhật một lần, tất cả cùng hưởng.
Đây là điểm tinh tế phân biệt SaaS làm tốt và SaaS làm ẩu: kẻ làm ẩu fork mã nguồn cho từng khách lớn, để rồi sa lầy trong việc bảo trì hàng chục phiên bản. Kẻ làm tốt giữ một nhân chung và cá nhân hoá bằng cấu hình.
Vì sao multi-tenant quan trọng với doanh nghiệp Việt?
- Chi phí thấp: hạ tầng chia sẻ giúp giá phần mềm phải chăng, phù hợp túi tiền SME.
- Cập nhật liên tục: tính năng mới, vá lỗi bảo mật, cập nhật theo quy định thuế mới (TT 78, NĐ 70/2025) được triển khai cho mọi khách hàng cùng lúc.
- Triển khai nhanh: doanh nghiệp đăng ký là dùng được ngay, không cần cài đặt máy chủ riêng.
Nền tảng est-invoice được thiết kế multi-tenant ngay từ nền móng: mỗi doanh nghiệp là một tenant cô lập, dữ liệu được bảo vệ nhiều lớp, và khả năng tuỳ biến được điều khiển bằng cấu hình thay vì phân nhánh mã. Việc xây dựng kiến trúc kiểu này đòi hỏi kinh nghiệm chuyên sâu — đây cũng là một trong những thế mạnh cốt lõi của giải pháp NKKTECH, khi kết hợp kiến trúc SaaS chuẩn mực với lớp AI tự động hoá nghiệp vụ.
Nếu bạn quan tâm cách AI vận hành bên trên kiến trúc này, hãy đọc thêm bài AI tự động hoá kế toán cho doanh nghiệp Việt.
Kết luận
Multi-tenant không chỉ là một lựa chọn kỹ thuật — nó là mô hình kinh tế giúp phần mềm chất lượng cao đến được với hàng nghìn doanh nghiệp với chi phí hợp lý. Nhưng sức mạnh đó đi kèm trách nhiệm: cách ly dữ liệu phải được thực thi nhiều lớp, tuỳ biến phải bằng cấu hình chứ không bằng phân mảnh mã. Khi đánh giá một nền tảng SaaS, hãy hỏi nhà cung cấp: dữ liệu của tôi được cô lập như thế nào, và ở bao nhiêu lớp?
Bài viết liên quan
Tự động hóa kế toán cho SME — 7 quy trình nên tự động hóa ngay 2026
Tự động hóa giúp team kế toán SME tiết kiệm hàng trăm giờ/năm. 7 quy trình đáng tự động hóa nhất: nhập hóa đơn (AI OCR), phân loại bút toán, đối chiếu ngân hàng, nhắc công nợ, khai thuế, báo cáo, lưu trữ chứng từ.
Bảo mật dữ liệu kế toán trên cloud có an toàn không? 8 điều cần kiểm tra
Nhiều chủ DN lo dữ liệu kế toán trên cloud bị mất hoặc lộ. Bài này phân tích thực tế: cloud vs máy chủ tại chỗ, 8 tiêu chí bảo mật cần kiểm tra (mã hóa, sao lưu, phân quyền, audit log, tuân thủ NĐ 13 PDPA), và quyền xuất dữ liệu.