Belajar Solution Architect - Multi-Tenant SaaS Solution

#Pendahuluan

Setelah di episode 19 solusi kalian bisa lolos audit dengan kontrol yang terbukti lewat evidence pipeline, kini kita bahas model bisnis yang mendominasi software modern: SaaS multi-tenant. Satu deployment melayani ratusan bahkan ribuan pelanggan — dan keputusan arsitektur kalian menentukan apakah setiap pelanggan tambahan memperbesar margin, atau justru merusak pengalaman pelanggan lama.

Mengapa ini topik SA penting? Karena multi-tenancy bukan fitur, melainkan keputusan fondasi yang menyentuh skema database, isolasi keamanan, operasi, dan struktur biaya sekaligus. Salah pilih di awal berarti re-platform mahal saat pelanggan enterprise pertama datang menuntut isolasi.

#Tiga Model Tenancy

Spektrum desainnya berkisar dari isolasi penuh sampai berbagi penuh:

Praktik industri yang matang adalah tiered tenancy: mayoritas pelanggan di pool (margin tinggi, operasi sederhana), pelanggan premium di bridge/silo dengan harga yang menutupi biayanya. Yang fatal adalah silo untuk semua — margin SaaS lenyap karena tiap pelanggan baru = satu cluster baru yang harus di-patch.

Keputusan ini layak ADR tersendiri dengan proyeksi angka: pada 1.000 tenant pool, biaya infra per tenant bisa seperseratus tenant silo. Angka semacam itulah yang membuat diskusi model tenancy objektif.

#Isolasi Data: Jantung Multi-Tenancy

Kesalahan fatal tunggal di SaaS adalah data tenant A bocor ke tenant B — insiden yang biasanya mengakhiri kontrak dan reputasi. Tiga pola penyimpanan sesuai model tenancy:

Pool    : tabel bersama + kolom tenant_id + row-level security (RLS)
Bridge  : schema/database terpisah per tenant di cluster sama
Silo    : cluster/database fisik terpisah per tenant

Untuk pool (paling umum), disiplin wajibnya:

1. Setiap tabel punya tenant_id — tanpa kecuali; query tanpa filter tenant harus gagal, bukan diam-diam mengembalikan semua baris.
2. Row-Level Security sebagai pengaman kedua — meski kode aplikasi lupa menambah filter, database menolak baris lintas tenant:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
 
CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.current_tenant')::uuid);
 
-- Aplikasi wajib set identitas tenant per koneksi/transaksi:
SET app.current_tenant = 'a1b2c3d4-...';

3. Identitas tenant diturunkan dari token, bukan dari parameter request — user tidak boleh "memilih" tenant-nya via query string.
4. Test anti-cross-tenant di CI — test otomatis yang login sebagai tenant A dan mencoba membaca resource tenant B; ia harus gagal selamanya.

Untuk object storage (e-tiket, upload), gunakan prefix per tenant plus IAM/policy yang memvalidasi path, dan hindari nama file yang dapat ditebak.

#Arsitektur Request-Aware Tenant

Di atas data layer, seluruh pipeline request harus sadar tenant sejak pintu masuk:

Komponen context ini menjadi tempat enforcement lintas halaman: rate limit per tenant, kuota storage per plan, routing ke instance khusus untuk tenant silo. Di sistem asinkron, pesan queue wajib membawa tenant_id di header — consumer meneruskan konteks yang sama sampai email terkirim.

#Pricing Tier Selaras Biaya Riil

Nilai arsitektur terbesar SA di SaaS adalah menyambungkan paket harga dengan biaya nyata per tenant. Caranya: definisikan unit konsumsi yang proporsional dengan beban infrastruktur — misal event processed, storage GB-bulan, atau API call — lalu petakan tier komersial ke limit teknisnya:

Tanpa sinkronisasi ini terjadi dua bencana klasik: tenant gratis menghabiskan biaya server premium (limit longgar), atau tenant bayar mahal dibatasi fitur yang murah bagi kalian (limit salah ukur). Metrik unit economics episode 9 dihitung per tenant di sini: biaya infra bulanan ÷ jumlah tenant aktif per tier.

Dua mekanisme teknis pendukung pricing:

• Quota enforcement runtime — metering usage per tenant (counter di Redis/warehouse) + middleware yang menolak/melembutkan saat limit tercapai, dengan respons yang informatif (upgrade hint).
• Metering untuk billing — agregat pemakaian dikirim ke sistem billing; pastikan idempotent dan audit-able, karena ini uang.

#Operasi Multi-Tenant: Noisy Neighbor dan Onboarding

Tantangan operasional spesifik model ini:

#Noisy Neighbor

Satu tenant menjalankan export raksasa jam 9 pagi dan semua tenant lain melambat. Pertahanannya berlapis:

• Rate limit & concurrency cap per tenant (bukan global) di gateway dan worker.
• Resource partitioning untuk workload berat: job export masuk antrian prioritas rendah dengan pool worker terpisah.
• Observability berdimensi tenant: latensi p95, error rate, dan konsumsi kuota harus bisa dilihat per tenant agar pelakunya ketemu dalam menit.

#Onboarding dan Offboarding Tenant Besar

• Onboarding tenant bridge/silo = provisioning otomatis via IaC (database baru, migrasi skema, DNS) — target menit, bukan minggu manual.
• Data migration masuk (import dari sistem lama tenant) butuh tooling sendiri dengan validasi record count/checksum — mirip disiplin migrasi episode 12.
• Offboarding = ekspor data sesuai hak subjek (episode 19) + purge terjadwal + dokumentasi kapan backup lama kedaluwarsa.

#Perubahan Skema Global

Deploy di SaaS menyentuh data semua tenant sekaligus:

• Migration harus backward compatible dua tahap (expand → migrate → contract): tambah kolom nullable dulu, backfill bertahap, baru hapus kolom lama — supaya rolling deploy aman tanpa downtime global.
• Backfill besar dijalankan throttled dan dipantau dampaknya ke latensi produksi; jangan pernah ALTER TABLE masif langsung di jam kerja.

#Checklist Desain Multi-Tenant SaaS

Rangkum episode ini menjadi checklist yang bisa dipakai langsung saat review proposal SaaS:

• Model tenancy dipilih dengan proyeksi biaya per tenant (pool default, silo hanya premium).
• Setiap tabel/storage/cache key/queue message membawa tenant identity; RLS aktif sebagai lapisan kedua.
• Test anti-cross-tenant berjalan di CI dan tidak pernah dilewati.
• Quota + metering per tier terhubung ke billing dan di-enforce runtime.
• Rate limit per tenant + observability berdimensi tenant siap hari pertama.
• Migration skema dua tahap dan provisioning tenant otomatis via IaC.

#Penutup

Inti yang harus dibawa pulang:

• Pilih model tenancy dari spektrum silo–bridge–pool berdasarkan segmentasi pelanggan dan margin; tiered tenancy adalah praktik standar.
• Isolasi data berlapis: tenant_id universal + RLS + identitas turunan token + test anti-cross-tenant; cache adalah celah nomor satu.
• Tenant context menyebar ke seluruh pipeline — termasuk pesan asinkron — dan menjadi titik enforcement quota/rate limit.
• Harga tier harus selaras dengan unit ekonomi infra per tenant; metering idempotent adalah jembatan arsitektur-billing.
• Operasi multi-tenant punya masalah unik: noisy neighbor, onboarding besar, dan skema global — semuanya butuh tooling, bukan heroik manual.

Di episode 21 selanjutnya kita akan membahas AI/LLM solution design — merancang solusi berbasis LLM yang benar: arsitektur RAG end-to-end, agent patterns dan guardrails-nya, evaluasi kualitas output yang terukur, serta strategi biaya dan privasi data pada solusi AI. Sampai jumpa di episode 21!