Arsitektur Multi-Tenant untuk Membangun Produk SaaS: Model Isolasi Data dan Cara Memilihnya

Banyak produk SaaS lahir dari aplikasi yang awalnya dibuat untuk satu perusahaan. Sistem itu berjalan baik, lalu ada perusahaan lain yang ingin memakainya, kemudian satu lagi. Pada titik ini pemilik produk menghadapi keputusan teknis yang dampaknya terasa bertahun-tahun: bagaimana melayani banyak pelanggan dari satu aplikasi tanpa data mereka bercampur, tanpa biaya server meledak, dan tanpa tim kewalahan setiap kali ada pembaruan.

Pola yang menjawab kebutuhan ini disebut arsitektur multi-tenant. Setiap pelanggan, atau tenant, memakai aplikasi yang sama tetapi datanya terpisah secara logis atau fisik. Artikel ini menjelaskan tiga model isolasi data yang umum, kelebihan dan risikonya, hal-hal yang sering terlupakan seperti kustomisasi dan penagihan, serta cara memilih model yang sesuai untuk tahap bisnis Anda.

Ringkasan

• Multi-tenant berarti satu aplikasi melayani banyak pelanggan, dengan data setiap pelanggan dipisahkan
• Tiga model utama adalah tabel bersama dengan kolom tenant, skema per tenant, dan database per tenant
• Tabel bersama paling hemat dan mudah diperbarui, tetapi butuh pengaman berlapis agar data tidak bocor antar tenant
• Database per tenant memberi isolasi terkuat untuk pelanggan besar atau teregulasi, dengan biaya operasional lebih tinggi
• Model campuran sering menjadi pilihan matang: tenant kecil berbagi, tenant enterprise mendapat database sendiri

Single-tenant atau multi-tenant?

Pada arsitektur single-tenant, setiap pelanggan mendapat salinan aplikasi dan database sendiri. Cara ini sederhana di awal dan terasa aman, tetapi setiap pelanggan baru berarti satu server lagi yang harus dipasang, dipantau, dicadangkan, dan diperbarui. Dengan sepuluh pelanggan masih bisa dikelola. Dengan seratus pelanggan, tim akan menghabiskan sebagian besar waktunya untuk merilis versi yang sama berulang kali, dan pelanggan cenderung berjalan di versi yang berbeda-beda.

Multi-tenant membalik keadaan itu. Satu kode, satu proses rilis, dan sumber daya dipakai bersama sehingga biaya per pelanggan turun. Tantangannya bergeser ke isolasi: memastikan pengguna perusahaan A tidak pernah melihat data perusahaan B, dan pelanggan yang sangat aktif tidak membuat aplikasi lambat bagi pelanggan lain. Keputusan antara keduanya terkait erat dengan model bisnis langganan yang ingin dijalankan, karena margin SaaS sangat bergantung pada biaya melayani setiap pelanggan.

Tiga model isolasi data

1. Tabel bersama dengan kolom tenant

Semua pelanggan menyimpan data di tabel yang sama, dan setiap baris memiliki kolom penanda tenant. Ini model paling hemat: satu database, satu skema, dan migrasi struktur cukup dijalankan sekali. Model ini cocok untuk produk dengan banyak pelanggan kecil hingga menengah.

Risikonya jelas: satu query yang lupa menyaring tenant dapat menampilkan data pelanggan lain. Karena itu pengaman tidak boleh hanya bergantung pada disiplin programmer. Database modern seperti PostgreSQL menyediakan row-level security, aturan di tingkat database yang otomatis membatasi baris yang bisa dibaca berdasarkan tenant yang sedang aktif. Gabungkan dengan lapisan akses data di aplikasi yang selalu menyertakan tenant, serta pengujian otomatis yang sengaja mencoba membaca data tenant lain.

2. Skema per tenant

Setiap pelanggan mendapat skema, semacam ruang terpisah, di dalam database yang sama. Isolasi lebih kuat karena tabelnya memang terpisah, dan mencadangkan atau memulihkan satu pelanggan lebih mudah. Kelemahannya muncul saat pelanggan bertambah: setiap perubahan struktur harus dijalankan di ratusan skema, dan satu migrasi yang gagal di tengah jalan membuat versi skema tidak seragam. Model ini cocok untuk jumlah tenant menengah dengan kebutuhan isolasi lebih tinggi.

3. Database per tenant

Setiap pelanggan mendapat database sendiri, sementara kode aplikasi tetap satu. Model ini memberi isolasi paling kuat, memungkinkan kunci enkripsi per pelanggan, pemulihan data per pelanggan ke titik waktu tertentu, dan memindahkan pelanggan besar ke server sendiri atau ke wilayah tertentu demi persyaratan lokasi data. Biayanya adalah operasional: setiap database perlu migrasi, cadangan, pemantauan, dan koneksi sendiri. Tanpa otomasi yang baik, model ini kembali terasa seperti single-tenant.

Model campuran untuk produk yang bertumbuh

Banyak produk SaaS yang matang memakai kombinasi. Pelanggan paket dasar berbagi tabel bersama, sedangkan pelanggan enterprise yang membayar lebih atau memiliki persyaratan regulasi mendapat database tersendiri. Aplikasi memakai direktori tenant, yaitu daftar yang mencatat lokasi data setiap pelanggan, lalu mengarahkan setiap permintaan ke database yang benar. Dengan cara ini, isolasi tambahan bisa dijual sebagai bagian dari paket harga, bukan menjadi beban untuk semua pelanggan.

Masalah tetangga yang berisik

Dalam sistem bersama, satu pelanggan yang mengimpor jutaan baris data atau menjalankan laporan berat dapat membuat aplikasi lambat bagi semua orang. Fenomena ini sering disebut noisy neighbor. Cara mengatasinya antara lain membatasi jumlah permintaan per tenant, memindahkan pekerjaan berat seperti impor dan laporan ke antrean latar belakang, memberi kuota penyimpanan sesuai paket, dan memantau pemakaian sumber daya per tenant. Teknik optimasi performa database seperti indeks yang diawali kolom tenant juga sangat membantu.

Hal yang sering terlupakan

• Kustomisasi per pelanggan: sediakan pengaturan, kolom tambahan, dan alur yang dapat dikonfigurasi, jangan bercabang kode per pelanggan
• Identitas dan akses: satu pengguna bisa menjadi anggota beberapa tenant, dan pelanggan enterprise sering meminta login lewat SSO perusahaan
• Penagihan: catat pemakaian per tenant sejak awal, karena paket harga hampir selalu berubah seiring produk bertumbuh
• Ekspor dan penghapusan data: pelanggan berhak mengambil datanya dan meminta penghapusan saat berhenti berlangganan
• Jejak audit per tenant: siapa melakukan apa dan kapan, terutama untuk pelanggan yang diaudit
• Lingkungan uji: pelanggan besar sering meminta lingkungan sandbox untuk menguji sebelum fitur baru aktif

Kebutuhan login perusahaan dibahas lebih rinci di artikel SSO dan manajemen identitas, sedangkan pengaturan peran pengguna di dalam setiap tenant mengikuti prinsip merancang hak akses pengguna.

Keamanan dan kepatuhan yang diminta pelanggan B2B

Begitu produk SaaS mulai dijual ke perusahaan menengah dan besar, tim pengadaan pelanggan hampir selalu mengirim kuesioner keamanan. Pertanyaannya antara lain: bagaimana data antar pelanggan dipisahkan, di mana data disimpan, apakah data dienkripsi saat disimpan dan dikirim, berapa lama cadangan disimpan, siapa saja di tim Anda yang bisa mengakses data pelanggan, dan bagaimana insiden dilaporkan. Jawaban yang jelas dan terdokumentasi mempercepat penjualan.

• Dokumentasikan model isolasi tenant dan pengaman berlapisnya dalam bahasa yang dipahami tim non-teknis
• Batasi dan catat akses staf internal ke data pelanggan, misalnya hanya lewat permintaan dukungan yang disetujui
• Siapkan rencana pemulihan per tenant, termasuk berapa lama data satu pelanggan bisa dipulihkan
• Patuhi aturan pelindungan data pribadi di negara pelanggan, termasuk kewajiban pemberitahuan jika terjadi kebocoran

Rilis dan pembaruan tanpa mengganggu pelanggan

Keuntungan utama multi-tenant adalah satu proses rilis untuk semua pelanggan. Keuntungan ini hanya terasa jika rilisnya aman. Gunakan pengujian otomatis dan CI/CD agar setiap perubahan teruji sebelum dirilis, migrasi database yang kompatibel ke belakang sehingga versi lama dan baru bisa berjalan bersamaan sesaat, dan feature flag untuk menyalakan fitur baru bertahap, misalnya ke tenant internal dulu, lalu sebagian pelanggan, baru semua.

Pantau juga kesehatan sistem per tenant, bukan hanya rata-rata. Rata-rata waktu respons yang baik bisa menyembunyikan satu pelanggan besar yang mengalami kelambatan parah. Observabilitas dan log yang mencatat penanda tenant membuat masalah seperti ini cepat terlihat.

Cara memilih model untuk tahap bisnis Anda

1. 01Perkirakan jumlah pelanggan dalam dua sampai tiga tahun dan ukuran data rata-rata per pelanggan
2. 02Identifikasi pelanggan yang terikat regulasi atau kontrak yang menuntut isolasi fisik atau lokasi data tertentu
3. 03Mulai dengan tabel bersama dan row-level security untuk sebagian besar produk B2B, kecuali ada alasan kuat sebaliknya
4. 04Pusatkan logika penentuan tenant di satu lapisan agar database terpisah bisa ditambahkan untuk pelanggan tertentu kemudian
5. 05Otomatiskan pembuatan tenant baru, dari pendaftaran sampai data awal, agar tidak bergantung pada pekerjaan manual
6. 06Tetapkan batas pemakaian dan pemantauan per tenant sebelum pelanggan besar pertama datang

Jika Anda sedang mengubah aplikasi internal menjadi produk SaaS, keputusan ini sebaiknya diambil bersama keputusan arsitektur lain seperti monolit atau microservices. Untuk sebagian besar produk tahap awal, monolit yang rapi dengan isolasi tenant yang kuat jauh lebih mudah dikelola daripada puluhan layanan kecil.

Pertanyaan yang sering diajukan

Apakah multi-tenant kurang aman dibanding single-tenant? Tidak selalu. Multi-tenant yang dirancang dengan pengaman berlapis bisa sangat aman, dan satu kode yang selalu diperbarui sering lebih aman daripada ratusan instalasi terpisah yang tertinggal versinya. Namun pelanggan tertentu tetap mungkin mensyaratkan isolasi fisik.

Bisakah aplikasi single-tenant yang sudah ada diubah menjadi multi-tenant? Bisa, tetapi butuh perencanaan: menambahkan penanda tenant ke data, menyesuaikan semua query, menggabungkan data dari banyak instalasi, dan menguji isolasinya. Proses ini mirip modernisasi sistem lama dan sebaiknya dilakukan bertahap.

Bagaimana dengan pelanggan yang meminta fitur khusus? Utamakan fitur yang bisa diaktifkan lewat pengaturan atau paket, sehingga tetap satu kode. Membuat cabang kode khusus untuk satu pelanggan menghilangkan keuntungan utama multi-tenant.

Berapa biaya membangun produk SaaS multi-tenant? Biayanya bergantung pada fitur, jumlah integrasi, dan tingkat isolasi. Isolasi yang baik menambah pekerjaan di awal, tetapi jauh lebih murah daripada memperbaiki kebocoran data atau memigrasi model isolasi setelah produk ramai dipakai.

Kesimpulan

Arsitektur multi-tenant adalah fondasi ekonomi produk SaaS: satu kode, satu rilis, dan biaya per pelanggan yang turun seiring pertumbuhan. Kuncinya adalah memilih model isolasi data yang sesuai dengan pelanggan dan regulasi Anda, menjaga isolasi itu berlapis, mengendalikan tetangga yang berisik, dan menyiapkan sejak awal hal-hal yang sering terlupakan seperti kustomisasi, penagihan, dan ekspor data. Keputusan yang tepat di awal membuat produk siap melayani sepuluh atau sepuluh ribu pelanggan tanpa membangun ulang.