Belajar 9router - Multi-tenant & Customer-specific Routing

#Pendahuluan

Di episode 8 kalian sudah bermain dengan traffic splitting, canary, shadowing, A/B testing, dan dynamic routing. Semua pola itu berasumsi satu pemilik traffic. Kini kita tambahkan dimensi yang membuat gateway AI masuk ranah enterprise: banyak pelanggan dalam satu gateway.

Episode 9 membahas multi-tenant dan customer-specific routing. Kita bedah tenant-aware route rules, per-customer model preferences, isolasi workload sensitif dengan SLA yang berbeda, serta custom routing berdasarkan user profile dan domain. Di akhir episode kalian bisa membangun gateway yang memperlakukan tiap pelanggan seperti gateway pribadinya masing-masing — tanpa mendeploy gateway terpisah.

#Konsep Multi-tenancy di 9router

Multi-tenancy berarti satu gateway melayani banyak tenant dengan aturan yang berbeda. Di 9router, setiap request diidentifikasi kepemilikannya lewat context — biasanya header atau klaim dari token otentikasi. Context ini dibawa sepanjang pipeline: policy evaluation, route matching, hingga pemilihan model, persis seperti yang mulai kalian kenal di episode 4.

tenants:
  - id: acme-corp
    domain: acme.example.com
    plan: enterprise
  - id: startup-labs
    domain: labs.example.dev
    plan: starter

Bila request masuk, 9router mencocokkan context request ke salah satu tenant. Keputusan routing kemudian bisa bergantung pada tenant itu. Ini berbeda dari sekadar label: tenant bisa memengaruhi policy mana yang aktif, model mana yang boleh dipakai, dan quota mana yang berlaku.

#Tenant-aware Route Rules

Route rules yang sadar tenant memungkinkan dua pelanggan yang mengirim pertanyaan serupa mendapat perlakuan berbeda. Misalnya tenant enterprise menginginkan model terkuat untuk semua request, sedangkan tenant starter dibatasi model ringan.

routes:
  - name: chat-enterprise
    match:
      tenant: acme-corp
      intent: chat
    target: gpt-4o
  - name: chat-starter
    match:
      tenant: startup-labs
      intent: chat
    target: gpt-4o-mini

Urutan route tetap dievaluasi dari atas ke bawah. Route chat-enterprise lebih spesifik karena menyebutkan tenant, jadi request dari acme-corp terpenuhi di sana dan tidak pernah jatuh ke route starter. Aturan ini juga memungkinkan tenant tertentu dipaksa lewat instance provider regional tertentu untuk kepatuhan. Daftar tenant aktif bisa dicek lewat 9router tenants list.

#Per-customer Model Preferences

Banyak pelanggan punya preferensi model sendiri — misalnya kontrak yang mensyaratkan Anthropic, atau kebutuhan agar embedding dan chat memakai provider yang sama. 9router menyimpan preferensi ini sebagai bagian profil tenant dan menerapkannya saat model selector bekerja.

tenants:
  - id: acme-corp
    preferences:
      chat_model: anthropic/claude-3-5-sonnet
      embedding_model: openai/text-embedding-3-large
      fallback_models: [openai/gpt-4o-mini]

Keputusan model akhir tetap bisa di-override oleh constraint lain — misalnya policy compliance dari episode 6 atau dynamic signal dari episode 8. Preferensi adalah default, bukan paksaan. Pastikan setiap override ini tercatat di log sebagai konteks, supaya kalian tahu kapan preferensi dilanggar dan alasannya.

#Isolasi Workload Sensitif dan SLA Berbeda

Tidak semua tenant sama pentingnya. Tenant dengan workload sensitif — data kesehatan, data keuangan, atau data anak — butuh isolasi lebih ketat: provider khusus, region khusus, dan konfigurasi tanpa berbagi konteks dengan tenant lain. Di sisi lain, tenant enterprise butuh SLA lebih tinggi dari tenant starter.

tenants:
  - id: health-plus
    plan: enterprise
    isolation:
      mode: dedicated
      provider_region: ap-southeast-1
      context_isolated: true
    sla:
      p95_latency_ms: 1500
      availability: 0.995
  - id: startup-labs
    plan: starter
    isolation:
      mode: shared
    sla:
      p95_latency_ms: 4000
      availability: 0.95

Isolasi dalam bentuk context_isolated memastikan state dan riwayat tidak pernah bocor antar tenant, sementara mode: dedicated menjamin kapasitas provider tidak berebut dengan tenant lain. SLA yang berbeda lalu direfleksikan ke quota, prioritas antrean, dan target observability — tenant enterprise mendapat jalur cepat saat provider penuh.

#Custom Routing Berbasis User Profile dan Domain

Lapisan paling granular: routing yang diputuskan dari profil user atau domain bisnis, bukan hanya tenant. Misalnya user admin mendapat akses tool analitik, user support diarahkan ke model yang hemat biaya, dan request dari domain tertentu diarahkan ke pipeline tool yang spesifik.

routes:
  - name: support-chat
    match:
      tenant: acme-corp
      role: support
    target: gpt-4o-mini
  - name: admin-tools
    match:
      tenant: acme-corp
      role: admin
      tool_scope: analytics
    target: gpt-4o
    tools: [analytics-query, report-generator]

Dengan atribut role dan tool_scope yang diambil dari token otentikasi, satu tenant bisa punya pengalaman routing berbeda per peran. Ini menjaga biaya: peran yang butuh model mahal mendapatkannya, peran yang tidak butuh diarahkan ke model hemat, dan akses tool dibatasi per profil user.

#Penutup

Multi-tenant routing mengubah satu gateway menjadi banyak gateway virtual. Tenant context menandai kepemilikan tiap request, tenant-aware rules memisahkan perlakuan antar pelanggan, preferensi model menjadi default yang bisa di-override dengan alasan tercatat, isolasi melindungi workload sensitif, dan SLA berbeda memastikan pelanggan premium didahulukan. Profil user dan domain menambahkan presisi hingga level peran.

Inti yang harus dibawa pulang:

• Context tenant mengalir dari otentikasi ke seluruh pipeline dan selalu direkam di logs serta metrics.
• Route rules bisa dicocokkan dengan tenant untuk menerapkan perlakuan berbeda dalam satu gateway.
• Preferensi model per customer adalah default; setiap override harus tercatat beserta alasannya.
• Isolasi konteks antar tenant adalah batas keamanan yang wajib diuji secara eksplisit.
• Routing berbasis role dan tool scope menjaga biaya dengan memberi model tepat ke peran yang tepat.

Di episode 10 kita beralih dari merancang ke mengelola: Configuration Management & Versioning — route config sebagai kode, validasi dan dry run, rollback yang aman, hingga evolusi konfigurasi untuk agent workflow jangka panjang. Sampai jumpa!