Belajar 9router - Sejarah, Latar Belakang & Mengapa Memilih 9router

#Pendahuluan

Di episode 0 kalian sudah menyiapkan environment: skill dasar, emulator lokal, dan kredensial LLM provider. Sekarang waktunya memahami mengapa tool ini ada. 9router tidak muncul dari ruang hampa — dia adalah hasil evolusi panjang dari teknologi gateway, dari yang paling sederhana sampai yang paling cerdas.

Roadmap episode ini: kita akan menelusuri evolusi gateway dari load balancer klasik, membandingkan tiga generasi teknologi (traditional API gateway, service mesh, dan AI routing gateway), lalu mengeksplorasi use case nyata yang membuat 9router relevan. Di akhir episode kalian akan tahu kapan dan mengapa sebuah tim membutuhkan AI routing gateway — dan bagaimana 9router menjawab kebutuhan itu.

#Evolusi Gateway: dari Load Balancer ke AI Routing Gateway

Istilah gateway sudah ada jauh sebelum AI lahir. Mari kita telusuri generasinya:

Load balancer lahir untuk menjawab masalah sederhana: beberapa server melayani aplikasi yang sama, jadi traffic harus dibagi agar tidak ada server yang kewalahan. Keputusannya statis dan berbasis beban — round-robin, least connections, atau berdasarkan health check. Ia tidak peduli apa isi request, hanya berapa banyak.

Seiring waktu, muncul kebutuhan untuk mengarahkan berdasarkan konten: /api ke service A, /web ke service B. Reverse proxy dan API gateway menangani ini dengan aturan berbasis path dan host. Semua generasi ini memutuskan berdasarkan struktur, bukan makna.

Di sinilah titik lompatan besar: ketika aplikasi mulai memanggil LLM, pertanyaan routing berubah dari "server mana?" menjadi "model mana, dengan provider apa, dan dengan kebijakan apa?". Sebuah request berisi prompt — teks bahasa alami yang punya intensi. Menentukan model yang tepat untuk intensi itu tidak bisa lagi dilakukan dengan membandingkan string path. Inilah yang coba dipecahkan AI routing gateway.

#Traditional API Gateway vs Service Mesh vs AI Routing Gateway

Ketiga teknologi ini sering disamakan padahal menyelesaikan masalah yang berbeda. Berikut perbandingannya:

API gateway tradisional bekerja di lapisan transport dan struktur: kalau path mengandung /v1/orders dan API key valid, teruskan ke backend tertentu. Keputusan ini deterministik dan cepat, tapi buta terhadap konten payload.

Service mesh beroperasi satu lapis di bawah: ia menyisipkan proxy (sidecar) di setiap service dan menangani komunikasi antar service — enkripsi mTLS, retry otomatis, dan traffic shifting. Ia menjaga jejaring, bukan pintu masuk.

AI routing gateway mengambil keputusan di lapisan semantik. Ia membaca isi request — termasuk prompt-nya — lalu memutuskan model mana yang paling cocok, kebijakan apa yang berlaku, dan provider mana yang harus dipanggil. Ini adalah kategori yang berbeda: gateway sebelumnya mengarahkan panggilan, sementara AI routing gateway mengarahkan pemikiran.

#Use Case: Prompt Routing

Prompt routing adalah praktik mengarahkan prompt yang masuk ke model yang paling tepat. Bayangkan sebuah asisten pelanggan yang menerima tiga jenis pertanyaan: pertanyaan ringan seperti "jam buka toko", pertanyaan teknis yang butuh reasoning, dan pertanyaan berbahasa yang butuh model dengan dukungan multibahasa kuat.

Tanpa prompt routing, semua pertanyaan dikirim ke satu model besar — mahal dan lambat untuk pertanyaan ringan. Dengan prompt routing, pertanyaan ringan diarahkan ke model kecil yang murah dan cepat, pertanyaan teknis ke model besar yang kuat, dan pertanyaan multibahasa ke model spesialis. Hasilnya: biaya turun, latensi membaik, dan kualitas tetap terjaga.

#Use Case: Multi-Model Orchestration

Aplikasi AI modern jarang memakai satu model. Sebuah produk bisa mengombinasikan model untuk conversation (LLM), model embedding untuk semantic search, model code untuk analisis kode, dan model vision untuk memahami gambar. Setiap kategori punya provider dan karakteristik biaya yang berbeda.

Multi-model orchestration adalah seni mengatur semuanya lewat satu pintu masuk. Aplikasi tidak perlu tahu provider mana yang menangani jenis request apa — ia cukup mengirim request ke 9router dengan metadata seperti task type, dan gateway yang memutuskan:

routes:
  - name: chat
    match:
      taskType: conversation
    target: anthropic
  - name: embed
    match:
      taskType: embedding
    target: openai-embedding
  - name: code
    match:
      taskType: code
    target: openai-code

Contoh di atas menunjukkan bagaimana 9router memisahkan model berdasarkan kategori tugas. Aplikasi cukup mengirim field task type, dan gateway meneruskannya ke stack yang tepat.

#Use Case: Policy-Based Model Selection

Model selection jarang murni soal teknis — selalu ada dimensi kebijakan. Beberapa request harus menggunakan provider yang sesuai dengan aturan data residency (data tidak boleh meninggalkan region tertentu). Sebagian pengguna berlangganan tier premium sehingga berhak atas model kelas atas, sementara pengguna gratis dibatasi ke model standar.

Policy-based model selection menggabungkan kriteria ini ke dalam keputusan routing: siapa penggunanya, dari mana request berasal, dan aturan bisnis apa yang berlaku. Jika aturan ini ditulis sebagai konfigurasi deklaratif, maka ia bisa di-review, diuji, dan di-rollback seperti kode biasa — jauh lebih aman daripada logika yang terpendam di dalam kode aplikasi.

curl -X POST http://localhost:8080/v1/chat \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"Ringkas dokumen ini","user":{"tier":"premium","region":"ap-southeast-1"}}'

Berdasarkan payload di atas, 9router bisa memutuskan bahwa pengguna premium berhak atas model besar, sementara region menentukan provider mana yang boleh digunakan. Semua keputusan ini terjadi di gateway, bukan di aplikasi. Agar pola ini mudah diuji, biasakan memvalidasi konfigurasi policy dengan 9router validate setiap kali berubah.

#Mengapa Memilih 9router

Dari semua pembahasan di atas, kita bisa merangkum alasan utama memilih 9router:

• Satu titik kontrol: seluruh kebijakan routing, model selection, dan safety terkumpul di satu tempat, bukan tersebar di kode aplikasi.
• Konfigurasi deklaratif: route dan policy ditulis sebagai kode, sehingga bisa di-version control, di-review, dan diuji.
• Provider-agnostic: aplikasi tidak terikat pada satu LLM provider; swap provider cukup dengan mengubah konfigurasi.
• Optimasi biaya dan latensi: prompt routing mengarahkan request ke model yang paling murah dan cepat untuk kebutuhan itu.
• Safety dan policy: kebijakan compliance, privacy, dan akses diterapkan secara konsisten di satu lapisan.

Penting untuk diingat bahwa 9router bukan pengganti API gateway atau service mesh — ia melengkapi keduanya. Di arsitektur modern, API gateway tetap menjaga pintu masuk aplikasi, service mesh menjaga komunikasi internal, dan 9router berdiri khusus untuk mengelola lalu lintas menuju LLM dan tools.

#Penutup

Di episode 1 ini kalian sudah memahami mengapa AI routing gateway lahir: evolusi dari load balancer yang memutuskan berdasarkan beban, menuju gateway yang memutuskan berdasarkan makna request. Kalian juga sudah membandingkan tiga kategori teknologi gateway dan mengenal tiga use case utama — prompt routing, multi-model orchestration, dan policy-based model selection — plus alasan memilih 9router sebagai solusinya.

Inti yang harus dibawa pulang:

• Evolusi gateway bergerak dari keputusan berbasis struktur menuju keputusan berbasis intent.
• API gateway menangani struktur, service mesh menangani jaringan, AI routing gateway menangani makna.
• Prompt routing menghemat biaya dan menurunkan latensi dengan memilih model yang paling tepat.
• Multi-model orchestration menuntut satu pintu masuk untuk conversation, embedding, code, dan vision.
• Policy-based model selection menyatukan aturan bisnis, region, dan tier pengguna ke dalam keputusan routing.

Di episode 2 selanjutnya kita akan membongkar konsep dasar dan arsitektur utama 9router — route engine, model selector, policy engine, observability layer, alur intent extraction hingga tool invocation, dan posisi 9router di antara klien, LLM provider, serta downstream tools. Persiapkan konfigurasi mental kalian, karena episode berikutnya akan sangat teknis!