Arsitektur Multi-Tenant Database untuk Aplikasi SaaS (Software as a Service)

Tantangan Skalabilitas di Model Bisnis B2B

Membangun aplikasi untuk satu perusahaan (Sistem Informasi Internal) itu mudah. Tapi saat kamu membangun produk SaaS (Software as a Service)—seperti aplikasi HRD, Kasir (POS), atau Sistem Akuntansi yang akan disewakan ke ratusan perusahaan berbeda—tantangan terbesarmu adalah Isolasi Data.

Setiap perusahaan pelanggan disebut sebagai Tenant (Penyewa). Karyawan dari PT Maju Jaya (Tenant A) sama sekali tidak boleh melihat laporan keuangan dari CV Makmur (Tenant B). Ada 3 pola arsitektur utama untuk menyelesaikan teka-teki Multi-Tenancy ini.

1. Pendekatan Terpisah: 1 Database untuk 1 Tenant (Silo)

Pola ini adalah yang paling eksklusif dan aman secara isolasi. Jika kamu punya 100 perusahaan pelanggan, kamu benar-benar membuat 100 buah Database MySQL yang terpisah di *server*.

• Kelebihan: Keamanan data tingkat militer. Jika Database PT Maju Jaya rusak atau diretas, 99 perusahaan lainnya tetap aman 100%. *Backup* (pencadangan) dan *Restore* data per klien sangat mudah dilakukan.
• Kelemahan: Biaya operasional (*Server Cost*) sangat mahal dan tidak masuk akal untuk skala *Startup*. Bayangkan kerepotannya jika kamu ingin menambahkan 1 kolom baru di tabel Products; kamu harus menjalankan Migration script di 100 database yang berbeda!

2. Pendekatan Tengah: 1 Database Besar, Beda Skema (Schema per Tenant)

Pendekatan ini populer di database PostgreSQL. Semuanya berada di dalam satu Mesin Database fisik, namun di dalamnya dipartisi secara logis menggunakan Schema (ruang lingkup khusus).

• Kelebihan: Cukup aman dan lebih murah karena masih dalam satu instansi *server* yang sama. Manajemen memori server lebih efisien.
• Kelemahan: *Query* dan Migration tetap harus dieksekusi berulang-ulang untuk setiap Skema. Terlalu banyak skema (Ribuan) juga bisa menurunkan performa Connection Pooling di Postgres.

3. Pendekatan Satuan: Shared Database, Shared Schema (Paling Populer)

Inilah metode yang digunakan oleh 90% Startup B2B modern (seperti Shopify atau aplikasi absensi). SEMUA data dari semua perusahaan pelanggan (Tenant) dicampur aduk ke dalam 1 Tabel Database yang sama.

Bagaimana cara membedakannya? Pada setiap tabel (Tabel Karyawan, Tabel Transaksi), wajib disematkan kolom tambahan bernama tenant_id.

• Kelebihan: Sangat murah, efisien, dan super mudah dirawat (*Maintain*). Menambah kolom atau memperbaiki relasi cukup dilakukan sekali karena tabelnya cuma satu. Menambah Tenant baru (perusahaan baru mendaftar) prosesnya instan dan tidak butuh persiapan *server*.
• Kelemahan dan Resiko Fatal: Satu kesalahan kode bisa berujung tuntutan hukum! Jika kamu lupa menyelipkan WHERE tenant_id = ? di satu query *backend*, karyawan PT A bisa tiba-tiba melihat slip gaji karyawan PT B! Solusi terbaiknya adalah menggunakan fitur Global Scopes pada framework ORM-mu (seperti di Laravel atau Prisma) untuk memastikan filter tenant_id selalu disuntikkan secara otomatis di setiap query SELECT/UPDATE tanpa terkecuali.