Arsitektur Multi-Tenant: Mengapa Dialer Membutuhkannya?

Jika Anda menjalankan BPO, bisnis reseller, atau operasi apa pun yang melayani banyak klien pada platform dialer yang sama, multi-tenancy bukanlah sekadar fitur tambahan yang bagus. Ini adalah fondasi yang menjadi dasar dari segala hal lainnya.

Apa Arti Sebenarnya dari Multi-Tenancy?

Multi-tenancy berarti beberapa klien independen (tenant) berbagi infrastruktur perangkat lunak yang sama sambil memiliki data, konfigurasi, dan aturan kepatuhan yang sepenuhnya terisolasi. Setiap tenant beroperasi seolah-olah mereka memiliki sistem khusus mereka sendiri — tetapi platform yang mendasarinya digunakan bersama.

Kata kuncinya adalah isolasiBukan pemisahan. Bukan penyaringan. Isolasi.

Mengapa Isolasi Itu Penting

Perlindungan data. Kontak, rekaman panggilan, data agen, dan hasil kampanye Klien A harus tidak terlihat oleh Klien B. Bukan hanya disembunyikan — tetapi terbukti tidak dapat diakses. Jika pengembang membuat kesalahan dalam kueri, basis data tetap harus mencegah akses data lintas tenant.

Independensi kepatuhan. Klien A mungkin beroperasi di bawah aturan TDRA (UEA). Klien B di bawah CITC (Arab Saudi). Klien C di bawah TCPA (AS). Setiap tenant membutuhkan aturan kepatuhan, daftar DNC , jam panggilan, dan pelacakan persetujuan masing-masing. Pelanggaran kepatuhan oleh satu tenant tidak dapat memengaruhi tenant lainnya.

Isolasi perekaman. Rekaman panggilan adalah data paling sensitif di pusat kontak. Rekaman setiap tenant harus disimpan di jalur penyimpanan terisolasi dengan kontrol akses khusus tenant. URL yang ditandatangani untuk rekaman Klien A tidak boleh pernah berfungsi untuk Klien B.

Isolasi penagihan. Setiap tenant memiliki jumlah agen, metrik penggunaan, dan siklus penagihan sendiri. Data penagihan harus akurat per tenant, tanpa adanya kontaminasi silang.

Cara yang Salah: Pemfilteran Tingkat Aplikasi

Banyak aplikasi panggilan otomatis menerapkan "multi-tenancy" dengan filter sederhana dalam kode aplikasinya. Setiap permintaan akan menambahkan filter ini. Cara ini berhasil... sampai seseorang lupa.

Permasalahan-permasalahan tersebut:

• Satu filter yang terlewat = kebocoran data antar tenant
• Kueri kompleks dengan join mudah salah dibuat.
• Kueri agregasi (laporan, dasbor) sangat berisiko.
• Tidak ada jaring pengaman ketika aplikasi membuat kesalahan.

Penyaringan tingkat aplikasi bukanlah isolasi. Ini adalah penyaringan upaya terbaik yang bergantung pada setiap pengembang, pada setiap kueri, di setiap jalur kode untuk melakukannya dengan benar 100% setiap saat. Itu tidak cukup baik.

Cara yang Tepat: Isolasi Tingkat Basis Data

DialerBee menggunakan PostgreSQL Row Level Security (RLS) sebagai lapisan pertahanan berlapis. Berikut cara kerjanya:

1. Setiap meja milik tenant memiliki kolom.
2. Kebijakan RLS diaktifkan dan DIPAKSA pada setiap tabel tenant.
3. Pada awal setiap transaksi basis data, kami menetapkan
4. Basis data itu sendiri menyaring setiap kueri — SELECT, INSERT, UPDATE, DELETE — untuk hanya mengembalikan baris yang sesuai dengan tenant saat ini.
5. Pengguna aplikasi tidak memiliki izin BYPASSRLS — bahkan SQL mentah pun tidak dapat lolos dari filter.

Artinya, meskipun kode aplikasi memiliki bug — misalnya, klausa WHERE yang hilang, JOIN yang salah, atau agregasi tanpa pengelompokan — basis data akan mencegah akses data lintas tenant. Filter aplikasi adalah pertahanan utama. RLS adalah jaring pengaman.

Pengujian Isolasi

Mengklaim isolasi saja tidak cukup. Anda perlu membuktikannya. DialerBee menjalankan pengujian isolasi tenant yang bersifat antagonis pada setiap titik akhir API :

1. tenant A membuat sumber daya (kontak, kampanye, rekaman, dll.)
2. tenant B mencoba melakukan GET, PATCH, DELETE pada sumber daya tersebut.
3. Setiap upaya harus mengembalikan kode 404 (tidak ditemukan), tidak pernah 403 (dilarang).

Mengapa 404 dan bukan 403? Karena 403 ("Anda tidak memiliki izin") mengkonfirmasi bahwa sumber daya tersebut ada. 404 ("tidak ditemukan") tidak mengungkapkan apa pun. tenant B bahkan seharusnya tidak tahu bahwa sumber daya tersebut ada.

Pengujian ini dijalankan di CI (Continuous Integration) pada setiap perubahan kode. Jika ada pengujian yang gagal, kode tersebut tidak akan digabungkan.

Apa yang Seharusnya Dituntut oleh Para Mitra

Jika Anda sedang mengevaluasi aplikasi dialer untuk penggunaan white-label atau reseller, ajukan pertanyaan-pertanyaan berikut:

• Apakah isolasi tenant diberlakukan pada tingkat basis data, atau hanya pada kode aplikasi?
• Bisakah Anda menunjukkan kepada saya rangkaian uji isolasi adversarial?
• Apa yang terjadi jika sebuah kueri secara tidak sengaja menghilangkan filter tenant?
• Apakah rekaman panggilan disimpan di jalur yang terisolasi untuk setiap tenant?
• Apakah pelanggaran kepatuhan yang dilakukan oleh satu tenant dapat memengaruhi tenant lainnya?
• Jika saya membuat tenant melalui portal mitra, apakah tenant tersebut langsung terisolasi dari semua tenant lainnya?

Jika jawaban atas salah satu pertanyaan ini tidak jelas, teruslah mencari. Penerapan multi-tenancy yang salah lebih buruk daripada tidak menerapkan multi-tenancy sama sekali — karena Anda memiliki rasa aman yang palsu.

Pertanyaan yang Sering Diajukan

Apa arti multi-tenancy dalam sebuah dialer?

Beberapa klien berbagi satu platform sementara data, konfigurasi, aturan kepatuhan, rekaman, dan pelaporan mereka tetap terpisah, sehingga tidak ada tenant yang dapat melihat atau memengaruhi tenant lain.

Mengapa penyaringan tingkat aplikasi saja tidak cukup?

Jika isolasi bergantung pada setiap kueri yang mengingat untuk memfilter berdasarkan tenant, satu filter yang terlewatkan akan menyebabkan kebocoran data. Batasan tersebut harus ditegakkan di bawah aplikasi, bukan melalui disiplin pengembang.

Bagaimana seharusnya isolasi diuji?

Lakukan upaya akses lintas tenant secara sengaja — minta catatan, rekaman, dan laporan tenant lain menggunakan sesi yang valid — dan pastikan platform menolak, daripada berasumsi bahwa platform menolak.

Apa yang seharusnya diminta oleh reseller atau BPO?

Bukti isolasi tingkat basis data, akses pengawas yang terbatas, konfigurasi kepatuhan per tenant, dan pelaporan serta penagihan terpisah per klien.