Kenapa multi tenancy adalah keputusan arsitektur, bukan fitur
Setiap platform yang melayani banyak klien pada satu instalasi harus menjawab satu pertanyaan mendasar: bagaimana memastikan data satu klien tidak pernah terlihat oleh klien lain. Ini bukan fitur yang bisa ditambahkan belakangan, melainkan keputusan yang memengaruhi hampir setiap baris kueri, setiap laporan, dan setiap unggahan berkas.
Kesalahan pada lapisan ini punya konsekuensi yang berbeda dari bug biasa. Bug fungsional membuat fitur tidak jalan, sedangkan bug isolasi tenant membocorkan data pelanggan, dan itu adalah insiden yang sulit dipulihkan secara reputasi.
Tiga pola isolasi yang umum
- Basis data terpisah per tenant. Isolasi paling kuat dan paling mudah dijelaskan ke klien yang menuntut jaminan. Biaya operasionalnya tinggi: migrasi harus dijalankan pada banyak basis data, dan pemantauan menjadi rumit saat jumlah tenant besar.
- Skema terpisah dalam satu basis data. Kompromi di tengah. Isolasi cukup jelas, tetapi jumlah skema yang sangat besar bisa menimbulkan masalah performa pada beberapa mesin basis data.
- Tabel bersama dengan kolom tenant. Paling hemat sumber daya dan paling mudah dioperasikan pada skala besar, tetapi paling rentan terhadap kesalahan manusia karena setiap kueri harus menyertakan filter tenant.
Untuk sebagian besar CRM percakapan, pola tabel bersama adalah pilihan yang paling praktis, dengan syarat disiplin penegakan filter dijalankan secara sistematis, bukan diserahkan pada ingatan pengembang.
Pertahanan berlapis yang sebaiknya dipasang
- Penegakan di lapisan akses data. Setiap kueri melewati satu jalur yang menambahkan filter tenant secara otomatis, sehingga tidak ada kueri yang bisa ditulis tanpa filter.
- Penegakan di lapisan middleware. Identitas tenant diambil dari sesi terotentikasi, bukan dari parameter permintaan yang bisa dimanipulasi klien.
- Penegakan di basis data. Kebijakan keamanan tingkat baris memberi lapisan terakhir yang tetap bekerja meskipun kode aplikasi keliru.
- Kunci komposit yang menyertakan tenant pada relasi antar tabel, sehingga referensi silang antar tenant menjadi tidak mungkin secara struktural.
Tempat kebocoran paling sering terjadi
Pengalaman menunjukkan kebocoran jarang terjadi pada kueri utama yang sering diuji. Yang berisiko adalah bagian pinggir:
- Laporan dan agregasi, yang sering ditulis sebagai kueri khusus di luar jalur akses data standar.
- Fitur ekspor, terutama ekspor besar yang berjalan sebagai tugas latar belakang.
- Pencarian global, apalagi kalau memakai mesin pencari terpisah yang perlu penyaringan sendiri.
- Berkas media. Tautan berkas yang bisa ditebak atau tidak diperiksa kepemilikannya adalah kebocoran yang sering terlewat karena tidak melewati basis data.
- Tugas latar belakang dan antrean. Pekerjaan yang berjalan di luar konteks permintaan pengguna sering kehilangan identitas tenant kalau tidak dibawa secara eksplisit.
- Webhook masuk. Payload dari pihak ketiga harus dipetakan ke tenant yang benar berdasarkan data terverifikasi, bukan berdasarkan nilai yang dikirim pengirim.
Cara menguji isolasi secara sistematis
- Uji integrasi dengan dua tenant. Setiap pengujian membuat data pada dua tenant berbeda lalu memastikan permintaan sebagai tenant pertama tidak pernah mengembalikan data tenant kedua.
- Uji negatif pada setiap endpoint. Coba akses identitas sumber daya milik tenant lain dan pastikan jawabannya konsisten, tidak membocorkan keberadaan sumber daya tersebut.
- Pemeriksaan otomatis pada kode. Aturan linter atau pemeriksaan yang menandai kueri langsung yang tidak melewati jalur akses data standar.
- Uji tugas latar belakang secara terpisah, karena inilah bagian yang paling jarang tercakup pengujian.
Pertimbangan performa dan operasional
- Indeks harus diawali kolom tenant pada tabel besar, karena hampir semua kueri menyaring berdasarkan tenant terlebih dahulu.
- Waspadai tenant raksasa. Satu klien dengan volume jauh di atas rata-rata bisa memengaruhi performa tenant lain kalau tidak ada pembatasan sumber daya.
- Terapkan batas laju per tenant, bukan hanya global, supaya satu klien tidak menghabiskan kapasitas bersama.
- Rencanakan penghapusan data per tenant. Ketika klien berhenti, Anda harus bisa menghapus atau mengekspor seluruh datanya secara lengkap dan terverifikasi.
Pertanyaan yang sering diajukan
Apakah basis data terpisah selalu lebih aman?
Lebih mudah dijamin, tetapi tidak otomatis lebih aman. Kesalahan konfigurasi koneksi atau kredensial yang terlalu luas tetap bisa membocorkan data. Yang menentukan adalah disiplin penerapan, bukan pola semata.
Bagaimana menangani klien yang menuntut basis data sendiri?
Sediakan sebagai opsi penerapan terpisah dengan harga berbeda. Memaksakan pola ini untuk semua tenant akan membebani operasional tanpa manfaat setara.
Apakah bisa berpindah pola di kemudian hari?
Bisa, tetapi mahal. Berpindah dari tabel bersama ke basis data terpisah lebih mudah daripada sebaliknya, karena data sudah tersegmentasi secara logis sejak awal.
Bagaimana dengan kepatuhan residensi data?
Kalau Anda melayani negara dengan aturan residensi data, rencanakan penerapan per wilayah sejak awal. Menambahkannya setelah ratusan tenant berjalan adalah pekerjaan besar.
Langkah berikutnya
Audit satu per satu bagian pinggir yang disebut di atas pada sistem Anda, terutama ekspor, pencarian, berkas media, dan tugas latar belakang. Kebocoran hampir selalu ada di sana, bukan di kueri utama. Lihat pendekatan arsitektur WhatsCRM Hub di halaman produk.
