T
TUTUR
EN Dashboard
Multi-Tenant Architecture SaaS

Multi-Tenant AI Chat: Satu Platform, Banyak Chatbot

ARSAKA Team ·

Bayangkan Anda membangun chatbot AI untuk satu perusahaan. Knowledge base satu, konfigurasi satu, model AI satu. Sederhana. Sekarang bayangkan Anda harus melayani 100 perusahaan. Masing-masing punya knowledge base sendiri, preferensi model sendiri, dan tentu saja, data mereka tidak boleh bocor ke perusahaan lain.

Inilah tantangan multi-tenancy di platform AI chat, dan ini adalah masalah arsitektural yang harus dipikirkan dari awal, bukan ditambahkan belakangan.

Mengapa Multi-Tenancy untuk AI Chat?

Tanpa multi-tenancy, setiap tenant membutuhkan deployment terpisah: server sendiri, database sendiri, konfigurasi sendiri. Untuk 10 tenant mungkin masih manageable. Untuk 100 atau 1000 tenant, ini menjadi mimpi buruk operasional.

Multi-tenancy memberikan tiga keuntungan utama:

  • Efisiensi biaya: Satu deployment melayani banyak tenant. Biaya infrastruktur dibagi, bukan dimultiplikasi.
  • Skalabilitas: Menambah tenant baru hanya butuh konfigurasi, bukan provisioning server baru.
  • Manajemen terpusat: Update, patch, dan monitoring dilakukan di satu tempat untuk semua tenant.

Isolasi Data: Fondasi yang Tidak Bisa Dikompromikan

Di platform AI chat, data tenant mencakup percakapan, knowledge base, memori pengguna, dan konfigurasi. Kebocoran data antar tenant bukan hanya masalah teknis, ini masalah kepercayaan dan hukum.

TUTUR menerapkan isolasi di beberapa lapisan:

Lapisan Database

Setiap query ke database menyertakan filter tenant_id. Ini bukan opsional, ini adalah invariant yang tidak pernah boleh dilanggar. Tanpa tenant_id, query tidak akan dieksekusi.

SELECT * FROM conversations
WHERE tenant_id = 'tenant-abc'  -- SELALU ada
  AND user_id = 'user-123'
ORDER BY created_at DESC

Lapisan Vector Database

Knowledge base disimpan di Qdrant sebagai vektor embedding. Setiap tenant memiliki namespace terpisah di Qdrant. Ketika tenant A melakukan pencarian, hanya vektor milik tenant A yang dicari. Tidak ada kemungkinan hasil dari tenant B muncul.

Lapisan Session dan Memory

Percakapan dan memory disimpan dengan tenant_id sebagai bagian dari primary key komposit. Memory yang diekstrak dari percakapan tenant A tidak akan pernah muncul sebagai konteks di percakapan tenant B.

Konfigurasi Per Tenant

Setiap tenant memiliki kebutuhan berbeda. Perusahaan A mungkin membutuhkan model yang lebih akurat (GPT-4), sementara perusahaan B cukup dengan model yang lebih cepat dan murah (GPT-3.5). TUTUR mendukung konfigurasi yang bisa disesuaikan per tenant:

  • LLM Provider: Pilihan antara OpenAI, DeepSeek, Groq, atau provider lain yang didukung. Tenant bisa menggunakan provider berbeda.
  • Model: Setiap provider menyediakan beberapa model. Tenant bisa memilih model yang sesuai dengan kebutuhan akurasi dan budget mereka.
  • Temperature: Tingkat kreativitas respons AI. Customer support mungkin membutuhkan temperature rendah (0.1-0.3) untuk konsistensi, sementara brainstorming assistant mungkin membutuhkan temperature lebih tinggi (0.7-0.9).
  • RAG Settings: Threshold pencarian, jumlah dokumen konteks, dan strategi chunking bisa berbeda per tenant tergantung jenis knowledge base mereka.

Manajemen API Key Per Tenant

Setiap tenant memiliki API key sendiri untuk mengakses TUTUR. API key ini mengontrol:

  • Autentikasi: Memastikan hanya request yang sah yang diproses.
  • Rate limiting: Membatasi jumlah request per periode waktu untuk mencegah abuse.
  • Usage tracking: Mencatat penggunaan per tenant untuk billing dan monitoring.
  • Scope: Menentukan fitur apa saja yang bisa diakses oleh tenant tersebut.

API key bisa di-rotate tanpa downtime, dan tenant bisa memiliki beberapa key aktif sekaligus (misalnya untuk environment production dan staging).

Feature Flags Per Tenant

Tidak semua fitur tersedia untuk semua tenant. TUTUR menggunakan feature flags untuk mengontrol ketersediaan fitur:

  • Memory system: Tenant pada plan dasar mungkin hanya mendapat session memory, sementara plan premium mendapat 4-layer memory system lengkap.
  • Reranking: Fitur reranking meningkatkan akurasi pencarian tapi membutuhkan compute tambahan. Tersedia sebagai fitur premium.
  • Multi-language: Dukungan bahasa bisa di-enable/disable per tenant.
  • Custom prompts: Kemampuan mengkustomisasi system prompt hanya untuk tenant tertentu.

Feature flags dievaluasi di awal setiap request, memastikan tenant hanya mengakses fitur yang mereka bayar.

Tantangan Multi-Tenancy

Multi-tenancy bukan tanpa tantangan. Tiga masalah utama yang harus diatasi:

Noisy Neighbor

Satu tenant yang mengirim ribuan request per detik bisa mempengaruhi performa tenant lain. Solusinya: rate limiting per tenant, queue prioritization, dan resource quotas. Tenant yang melebihi batas dialokasikan ke queue terpisah agar tidak mengganggu yang lain.

Data Leakage

Bug sekecil apapun di lapisan isolasi bisa menyebabkan data satu tenant terlihat oleh tenant lain. Pencegahannya: tenant_id sebagai mandatory parameter di setiap layer (bukan hanya API), automated tests yang secara khusus menguji isolasi, dan code review yang memperhatikan setiap query tanpa filter tenant.

Fair Resource Allocation

LLM inference membutuhkan GPU yang mahal. Bagaimana memastikan semua tenant mendapat respons dalam waktu yang wajar? TUTUR menggunakan provider-level load balancing dan fallback. Jika satu provider overloaded, request dialihkan ke provider alternatif yang dikonfigurasi oleh tenant.

Pelajaran dari Implementasi

Beberapa pelajaran yang kami pelajari dalam membangun TUTUR sebagai platform multi-tenant:

  1. Tenant isolation harus di-design dari hari pertama. Menambahkan tenant_id ke sistem yang sudah jalan adalah migrasi yang menyakitkan. Jauh lebih mudah jika sudah ada dari awal.

  2. Test isolasi secara eksplisit. Buat test case yang mencoba mengakses data tenant A menggunakan kredensial tenant B. Ini harus gagal, selalu.

  3. Konfigurasi per tenant lebih penting dari yang Anda kira. Awalnya kami pikir satu konfigurasi cukup untuk semua. Ternyata setiap tenant punya kebutuhan unik yang tidak bisa disederhanakan.

  4. Monitoring per tenant adalah keharusan. Anda perlu tahu tenant mana yang menggunakan resource paling banyak, tenant mana yang mengalami error, dan tenant mana yang mendekati limit mereka.

Multi-tenancy menambah kompleksitas arsitektur, tapi ini adalah investasi yang membuat platform Anda scalable. Satu platform yang melayani banyak tenant jauh lebih sustainable dibandingkan banyak deployment yang masing-masing melayani satu tenant.