Satu pangkalan kod, ratusan penyewa, sifar kebocoran data — asas kepada setiap perniagaan SaaS yang berskala.

Anda sedang membina platform yang melayani berbilang pelanggan dari satu penggunaan. Setiap pelanggan menjangkakan data yang terpencil, pengalaman berjenama, dan pengebilan bagi setiap penyewa — tetapi anda tidak mampu untuk menjalankan infrastruktur yang berasingan untuk setiap satu. Anda memerlukan kecekapan ekonomi infrastruktur kongsi dengan jaminan pengasingan sistem khusus. Ini adalah ketegangan asas seni bina SaaS, dan kesilapan dalam model pengasingan pada peringkat awal adalah salah satu kesilapan yang paling mahal dalam pembangunan platform.
Explore more design patterns and system architectures
Arkitek kami dapat membantu merancang dan membina sistem menggunakan pola ini untuk keperluan khusus anda.
Hubungi KamiSeni bina SaaS pelbagai penyewa menyediakan pengasingan logik atau fizikal antara penyewa sambil berkongsi sumber pengkomputeran, storan dan rangkaian yang mendasari. Corak ini merangkumi penyediaan penyewa, pengasingan data, pengurusan ciri, pemeteran pengebilan, dan penyesuaian label putih. Keputusan reka bentuk utama adalah model pengasingan: pangkalan data kongsi dengan keselamatan peringkat baris (RLS), skema-per-penyewa, atau pangkalan data-per-penyewa. Setiap model mengimbangi kekuatan pengasingan dengan kerumitan operasi dan kecekapan kos.
Sistem ini diatur menjadi tiga lapisan. Get laluan peka penyewa mengendalikan pengesahan, penyelesaian penyewa (melalui subdomain, tuntutan JWT, atau kunci API), dan penghalaan permintaan. Lapisan aplikasi beroperasi sepenuhnya dalam konteks penyewa — setiap pertanyaan, setiap kunci cache, setiap mesej baris gilir diselaraskan kepada penyewa yang diselesaikan. Lapisan data menguatkuasakan pengasingan pada peringkat storan melalui dasar keselamatan peringkat baris, pengumpulan sambungan setiap penyewa, dan pemisahan yang disulitkan semasa rehat.
tenant_id. Untuk skema-per-penyewa: penghalaan sambungan dinamik dengan pengurusan kumpulan sambungan. Untuk pangkalan data-per-penyewa: automasi penyediaan dengan Terraform/Pulumiacme.yourapp.com) lebih bersih untuk produk label putih dan membenarkan sijil TLS bagi setiap penyewa. Berasaskan laluan (yourapp.com/acme/) lebih mudah untuk dilaksanakan dan mengelakkan kerumitan DNS wildcard. MW mengesyorkan resolusi subdomain untuk B2B SaaS dengan keperluan label putih, berasaskan laluan untuk alat pelbagai penyewa dalaman.tenant_id. Ini kedengaran jelas, tetapi pertembungan kunci cache merentasi penyewa adalah salah satu pepijat pelbagai penyewa yang paling biasa. Kami menguatkuasakan ini melalui kilang kunci cache yang menambah awalan konteks penyewa secara automatik.| Lapisan | Teknologi |
|---|---|
| Pengkomputeran | Node.js (NestJS), Python (FastAPI), dikontena pada ECS Fargate atau Kubernetes |
| Data | PostgreSQL dengan RLS, Redis (lingkungan penyewa), S3 (baldi berpecah penyewa) |
| Identiti | Clerk, Auth0, atau Okta dengan organisasi lingkungan penyewa |
| Pengebilan | Stripe Connect (model pasaran), Stripe Billing (langganan bermeter) |
| Kebolehcerapan | Datadog dengan tag dimensi penyewa, pengelogkan berstruktur dengan tenant_id pada setiap entri |
| Guna Apabila | Elak Apabila |
|---|---|
| Membina platform B2B yang melayani 10+ pelanggan dari infrastruktur kongsi | Setiap pelanggan memerlukan infrastruktur yang khusus sepenuhnya (pematuhan/kontrak) |
| Anda memerlukan penjenamaan label putih, domain tersuai, dan kawalan ciri bagi setiap penyewa | Anda mempunyai kurang daripada 3 pelanggan — penggunaan yang lebih mudah bagi setiap pelanggan mungkin mencukupi |
| Penetapan harga berasaskan penggunaan atau bertingkat memerlukan pemeteran bagi setiap penyewa | Produk tersebut adalah aplikasi pengguna dengan akaun peringkat pengguna, bukan penyewa peringkat organisasi |
| Anda mahukan satu saluran penggunaan, satu timbunan pemantauan, satu giliran panggilan | Penyewa mempunyai skema atau logik perniagaan yang berbeza secara asas (bukan hanya konfigurasi) |
MW menganggap multi-tenancy sebagai perhatian merentas fungsi, bukan ciri. Kami melaksanakan penyebaran konteks penyewa pada peringkat middleware supaya kod aplikasi tidak pernah menapis secara manual mengikut penyewa — ia dikuatkuasakan oleh rangka kerja. Pelaksanaan RLS kami termasuk suite ujian automatik yang cuba capaian data merentas penyewa pada setiap larian CI. Kami telah membina platform pelbagai penyewa yang melayani 500+ penyewa pada infrastruktur kongsi dengan sifar insiden kebocoran data, dan kami telah memindahkan monolit penyewa tunggal ke seni bina pelbagai penyewa menggunakan corak 'strangler fig'.
Model tidak berfungsi dengan sendirinya. Saluran paip yang melatih, mengesahkan, menggunakan, dan memantau model anda adalah produk sebenar — model hanyalah satu artifak.
Pilihan optimum bergantung pada tenant isolation requirements dan skala anda. MicrocosmWorks biasanya mengesyorkan shared-database, separate-schema approach untuk kebanyakan B2B SaaS products kerana ia mengimbangi kecekapan kos dengan data isolation, walaupun kami melaksanakan database-per-tenant untuk pelanggan dalam regulated industries seperti penjagaan kesihatan atau kewangan di mana data segregation yang ketat diwajibkan. Arkitek kami menilai compliance needs, expected tenant count, dan query patterns anda sebelum mengesyorkan tenancy model yang tepat.
MicrocosmWorks melaksanakan pengehadan kadar peka-penyewa, pengumpulan sambungan dengan kuota setiap penyewa, dan pengasingan sumber pada lapisan pengkomputan untuk mencegah masalah jiran bising. Kami menggunakan teknik seperti pengagihan giliran saksama berwajaran dan lapisan caching khusus penyewa supaya lonjakan mendadak daripada seorang pelanggan tidak menyebabkan kependaman kepada pelanggan lain. Untuk penyewa peringkat perusahaan, kami boleh menyediakan partition pengkomputan khusus sambil mengekalkan satah kawalan kongsi yang utuh.
MicrocosmWorks menawarkan perkhidmatan reka bentuk dan implementasi architecture pada kadar perundingan antara $15-$45/jam bergantung kepada kerumitan dan senioriti pasukan yang diperlukan. Satu libatan multi-tenant SaaS architecture yang tipikal—meliputi reka bentuk database, pengasingan tenant, authentication, dan deployment pipelines—berjalan 8-16 minggu dengan pasukan silang fungsi. Kami menentukan skop setiap projek dengan fasa penemuan harga tetap supaya anda mempunyai keterlihatan kos penuh sebelum komited kepada pembinaan.
MicrocosmWorks membina saluran paip penyediaan penyewa automatik yang mengendalikan penciptaan skema, konfigurasi DNS, inisialisasi bendera ciri, dan penggunaan data asas dalam beberapa minit selepas pendaftaran baru. Kami menggunakan alat infrastruktur sebagai kod seperti Terraform atau Pulumi digabungkan dengan aliran kerja berasaskan peristiwa supaya setiap penyewa baru mendapat persekitaran yang dikonfigurasi sepenuhnya tanpa campur tangan manual. Pendekatan ini membolehkan pelanggan kami skalakan dari 10 penyewa kepada 10,000 tanpa mengubah proses pendaftaran.
MicrocosmWorks melaksanakan lapisan penyesuaian berasaskan konfigurasi menggunakan feature flags, metadata khusus penyewa, dan seni bina plugin yang membenarkan tingkah laku mengikut penyewa tanpa pencabangan kod. Kami mereka bentuk titik-titik kebolehlanjutan pada theming UI, workflow engine, dan lapisan integrasi agar penyewa boleh mempunyai penjenamaan unik, peraturan perniagaan, dan sambungan pihak ketiga, semuanya diuruskan melalui konfigurasi. Ini memastikan pasukan kejuruteraan anda menyelenggara satu pangkalan kod sambil menyokong pelbagai keperluan pelanggan.