Arsitektur multi-tenant: keputusan yang benar-benar penting

Setiap produk B2B SaaS pada akhirnya menghadapi pertanyaan yang sama: bagaimana mengisolasi data pelanggan tanpa menduplikasi seluruh aplikasi untuk tiap tenant? Setelah mengirim 40+ platform SaaS production, kami melihat hanya ada beberapa keputusan yang menentukan apakah multi-tenancy akan scalable atau berubah menjadi rewrite dua tahun kemudian.

1. Pilih model isolasi sebelum menulis kode

Shared schema dengan kolom tenant_id adalah yang paling cepat diluncurkan, tetapi paling sulit diubah belakangan. Schema-per-tenant memberi isolasi lebih kuat dan backup per pelanggan yang lebih mudah, dengan biaya kompleksitas migrasi saat tenant bertambah. Database-per-tenant jarang perlu sebelum ada tuntutan compliance enterprise.

Kami biasanya memulai produk baru dengan shared schema dan row-level security di level database, bukan hanya di aplikasi. Perbedaannya bisa menjadi batas antara bug biasa dan kebocoran data.

"Batas tenant harus dijaga di tempat yang tidak bisa ditembus hanya karena satu WHERE clause lupa ditulis."

2. Billing dan provisioning selalu terhubung

Perubahan paket, penambahan seat, dan add-on berbasis usage harus memicu perubahan entitlement secara real time. Kami memperlakukan billing webhook sebagai source of truth, lalu menyinkronkan feature flag dalam hitungan detik.

3. Desain index untuk query tenant-scoped sejak hari pertama

Hampir semua query di aplikasi multi-tenant scoped ke satu tenant. Composite index yang diawali tenant_id menjaga query tetap cepat saat tabel tumbuh hingga puluhan juta baris.

Keputusan ini tidak gratis untuk dibalik. Jika model isolasi dan strategi indexing benar sejak awal, arsitektur multi-tenant akan tetap membosankan, dan itu hal yang bagus.