Cara Mendesain Multi Tenant System dengan Santai & Efektif
Pernah denger istilah multi tenant system? Bayangin kamu punya satu aplikasi SaaS (Software as a Service) yang dipakai puluhan bahkan ratusan klien. Setiap klien punya data sendiri-sendiri, tapi mereka semua pakai aplikasi yang sama. Itulah inti dari multi tenant — satu kode, banyak penyewa (tenant).
Nah, mendesain sistem kayak gini tuh butuh strategi biar nggak ribet di kemudian hari. Gak mau kan satu tenant error terus bikin tenant lain ikut-ikutan down? Atau yang lebih serem: data tenant A bocor ke tenant B? Nah, kita bahas cara mendesainnya dengan santai, langsung ke intinya.
1. Pilih Pendekatan Database yang Pas
Ini adalah keputusan paling krusial. Ada tiga cara umum:
– Database per Tenant: Setiap tenant punya database sendiri. Terisolasi total, paling aman. Cocok buat klien besar yang punya aturan keamanan ketat (misal: perbankan). Tapi biaya operasional tinggi, dan migrasi fitur baru bisa repot karena harus update ke semua database.
– Schema per Tenant: Cuma satu database, tapi setiap tenant punya schema (atau prefix tabel) sendiri. Misal: tabel `tenant1_users` dan `tenant2_users`. Lebih efisien dari poin pertama, tapi tetap butuh manajemen schema yang rapi.
– Shared Schema (Column-Based): Semua tenant dalam satu tabel. Dibedakan pakai kolom `tenant_id`. Paling hemat biaya, skalabilitas tinggi, tapi kode harus super hati-hati agar query selalu menyertakan `WHERE tenant_id = ?`. Kalau lupa, data tenant lain bisa keliaran.
Rekomendasi santai: Kalau kamu startup atau produk baru, mulai dengan shared schema dulu. Biaya rendah, cepat berjalan. Tapi siap-siap upgrade ke schema per tenant kalau klienmu mulai besar dan minta isolasi lebih ketat.
2. Bangun Context Tenant di Setiap Request
Setiap kali user login, aplikasi harus tahu siapa tenant-nya. Gunakan pendekatan:
– Subdomain: `tenantA.aplikasi.com` vs `tenantB.aplikasi.com`
– Path URL: `aplikasi.com/tenantA/dashboard`
– Custom Domain: `klien1.co.id` yang mengarah ke aplikasi kamu
Di backend, simpan tenant context di session atau di dependency injection. Di framework modern seperti Laravel atau Django, biasanya ada middleware yang membaca subdomain/domain, lalu menyetel koneksi database atau filter berdasarkan tenant tersebut.
3. Urus Isolasi Data dengan Ketat
Ini urusan paling krusial. Sebuah bug kecil bisa bikin data tenant bocor. Tips:
– Jangan pernah percaya pada filter di frontend. Selalu lakukan validasi tenant di backend.
– Buat global scope di ORM (Object Relational Mapping). Misal di Eloquent (Laravel) ada Global Scopes yang otomatis menambahkan `WHERE tenant_id = current_tenant`. Jadi programmer nggak perlu khawatir lupa.
– Kalau pakai database per tenant, ganti koneksi database berdasarkan tenant context. Pastikan koneksi default tidak bisa diakses tanpa tenant.
4. Optimasi Skalabilitas
Multi tenant yang sukses harus bisa tumbuh. Pertimbangkan:
– Caching per tenant: Cache Redis atau Memcached sebaiknya dibedakan per tenant. Atau minimal gunakan key prefix (`tenantA:users:123`).
– Job Queue terpisah: Kalau tenant A kirim ribuan email, jangan sampai bikin tenant B lambat. Pisahkan antrean job berdasarkan tenant (misal: queue_tenantA, queue_tenantB).
– Auto-scaling: Untuk shared schema, kalau traffic naik, kamu bisa tambah server aplikasi. Untuk database per tenant, kamu perlu strategi routing ke database masing-masing.
5. Manajemen Tenant & Billing
Dari sisi produk, kamu butuh fitur untuk:
– Membuat tenant baru (provisioning).
– Mengaktifkan/menonaktifkan tenant (misal karena gagal bayar).
– Menetapkan limitasi (storage, jumlah user, dll).
– Menyediakan dashboard untuk admin super yang bisa lihat semua tenant.
Gunakan tabel `tenants` yang berisi informasi seperti nama, subdomain, status, dan konfigurasi fitur. Saat tenant baru daftar, jalankan migrasi database (kalau pendekatan per database) atau insert data default ke tabel bersama.
6. Pengujian (Testing) Jangan Sampai Lengah
Testing di multi tenant itu tricky. Kamu harus pastikan:
– Query yang ditulis benar-benar membatasi tenant.
– Bila ada data yang di-share (misal: master data negara), pastikan tidak terfilter oleh tenant.
– Uji skenario: user A melihat dashboard, lalu ganti context ke tenant B (simulasi admin super). Pastikan data tidak tercampur.
Gunakan factory di testing yang membuat tenant berbeda-beda, lalu lakukan asersi bahwa data dari tenant lain tidak muncul.
Kesimpulan: Santai Tapi Tertata
Mendesain multi tenant system bukanlah ilmu roket, tapi butuh disiplin. Mulai dengan pendekatan paling sederhana (shared schema + global scope), lalu tingkatkan seiring kebutuhan. Yang terpenting: isolasi data harus jadi prioritas nomor satu. Jangan sampai pelangganmu saling lihat data satu sama lain — itu recipe for disaster.
Dengan arsitektur yang rapi, kamu bisa melayani 10 atau 10.000 klien dengan basis kode yang sama. Selamat mendesain, semoga aplikasi SaaS-mu laris manis!