Pertanyaan yang sering diajukan
- Haruskah mulai dengan database terpisah per tenant?
- Biasanya tidak—skema bersama dengan tenant_id ketat dan tes isolasi skala lebih jauh untuk kebanyakan B2B SaaS.
- Apa bug multi-tenant paling umum?
- Filter tenant hilang pada satu query—gunakan middleware dan tes integrasi yang gagal tertutup (fail closed).
- Kapan APLINDO merekomendasikan database silo?
- Tenant terregulasi, enterprise sangat besar, atau residensi data kontraktual yang tidak bisa berbagi cluster.
Founder minta fitur. Investor minta margin. Keamanan minta bukti tenant tidak bisa melihat data tenant lain. Lewatkan baseline, setiap fitur berikutnya membawa pelanggaran laten.
Apa yang masuk dalam baseline multi-tenant?
- Konteks tenant di mana-mana —
tenant_iddi baris, klaim JWT, log, metrik. - AuthZ default menolak — RBAC atau ABAC dengan tes kebijakan, bukan
if (user.isAdmin)ad-hoc. - Konfigurasi per tenant — Feature flag, branding, webhook tanpa redeploy monolith.
- Kontrol noisy-neighbor — Rate limit dan fairness antrian per tenant.
- Strategi migrasi — Cara onboard, offboard, dan ekspor data tenant (PDP relevan).
Bagaimana APLINDO mengimplementasikan ini?
Kami mengirim stack multi-tenant untuk produk seperti RTPintar, Patuh.ai, dan BlastifyX, plus SaaS kustom untuk enterprise Jakarta. Kami lebih suka pola row-level Postgres dengan tes integrasi eksplisit daripada kompleksitas shard-per-tenant prematur.
Poin penting
- Isolasi tenant adalah test suite, bukan komentar di README.
- Observability per tenant menghemat jam saat satu pelanggan melaporkan lambat.
- Tambah database silo hanya saat kontrak atau skala memaksa—bukan hari pertama.