Tujuan Pembelajaran

Memahami arsitektur multi-tenant: shared DB vs separate DB vs hybrid
Mampu mengimplementasikan tenant-aware authentication
Mengerti security isolation antar tenant dan common pitfalls

Analogi

Diagram


      Multi-Tenant = Apartemen vs Rumah:

Shared DB (Apartemen):
Semua tenant di satu gedung. Satu pintu masuk (auth server).
Perlu: kunci berbeda untuk setiap unit (tenant isolation di app level).

Separate DB (Rumah):
Setiap tenant punya rumah sendiri. Pintu masuk sendiri.
Aman, tapi mahal (infra overhead).

Hybrid: Shared untuk tenant kecil, dedicated untuk enterprise.
Perlu: routing yang tepat ke DB yang benar berdasarkan tenant.

Multi-tenant architecture seperti perumahan — shared (apartemen), separate (rumah), atau hybrid. Isolation adalah kunci.

Penjelasan Konsep

Multi-tenant auth adalah tantangan arsitektur yang signifikan — user ‘budi@email.com’ bisa ada di tenant A, B, dan C dengan role berbeda di masing-masing.

Arsitektur: (1) Shared Database — semua tenant di satu DB. Kolom tenant_id di setiap tabel. Paling sederhana, paling murah. Risiko: query lupa WHERE tenant_id → data leak antar tenant. (2) Separate Database — setiap tenant punya DB sendiri. Isolation sempurna. Untuk enterprise. (3) Hybrid — shared untuk small tenants, dedicated untuk enterprise.

Auth flow multi-tenant: (1) User login → dapatkan daftar tenant yang dimiliki. (2) Pilih tenant. (3) Issue access token dengan tenant context (tenant_id, tenant_role). (4) API middleware ekstrak tenant_id dari token, enforce isolation.

Security pitfalls: (1) Row-level security lupa diimplementasi → user tenant A bisa akses data tenant B. (2) Token tidak mengandung tenant context → API tidak tahu tenant mana. (3) Cross-tenant access — pastikan user tidak bisa switch ke tenant yang bukan miliknya.

Implementation: JWT claims dengan tenant_id + tenant_role. Database RLS (Row-Level Security) untuk enforcement di database level — double protection.

Inti yang Perlu Dipahami

Bagian ini berfokus pada memahami arsitektur multi-tenant: shared DB vs separate DB vs hybrid., mampu mengimplementasikan tenant-aware authentication., dan mengerti security isolation antar tenant dan common pitfalls. Jangan terburu-buru menghafal istilahnya. Lebih penting untuk memahami peran setiap konsep dan kapan konsep itu muncul dalam pekerjaan web development.

Saat membaca Multi-Tenant Auth Architecture, gunakan tujuan belajar sebagai penanda arah. Kalau kamu sudah bisa menjelaskan tujuan itu dengan kata-katamu sendiri, berarti fondasinya mulai terbentuk.

Cara Membayangkannya

Multi-tenant architecture seperti perumahan — shared (apartemen), separate (rumah), atau hybrid. Isolation adalah kunci. Analogi ini dipakai supaya konsep teknis tidak terasa melayang. Hubungkan setiap istilah dengan perannya: siapa yang meminta, siapa yang memproses, data apa yang berpindah, dan hasil apa yang diharapkan.

Kalau analoginya sudah terasa masuk akal, barulah lihat istilah teknisnya. Cara ini membuat materi lebih mudah dipahami daripada langsung menghafal definisi.

Konteks dalam Perjalanan Belajar

Setiap konsep di platform ini dipilih karena dipakai di industri. Fokus pada pemahaman, bukan hafalan.

Kamu sudah di bagian lanjutan. Mulai pikirkan bagaimana konsep ini dipakai di dunia kerja — bukan hanya untuk belajar, tapi untuk membangun produk nyata.

Gunakan pertanyaan reflektif dan prompt AI di akhir chapter sebagai latihan aktif. Membaca saja tidak cukup — kamu perlu menjelaskan ulang dengan kata-katamu sendiri.

Prompt AI

Desain multi-tenant auth untuk SaaS CRM. Tenant = perusahaan. User = karyawan perusahaan. Satu user bisa kerja di multiple perusahaan dengan role berbeda. Minta AI buat architecture diagram.

Pertanyaan Reflektif

Apakah aplikasi-mu perlu multi-tenant? Kalau iya, apakah data isolation antar tenant sudah dijamin di database level (RLS), atau hanya di application level?