Belajar 9router - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kalian sudah memahami mengapa AI routing gateway dibutuhkan dan use case yang memotivasinya. Sekarang saatnya membongkar bagian dalam mesin: bagaimana 9router bekerja dari request masuk hingga respons kembali. Ini adalah episode paling fundamental di fase awal series — semua episode berikutnya akan merujuk pada konsep yang kalian pelajari di sini.

Roadmap episode ini: kita akan melihat gambaran besar arsitektur, membedah empat komponen inti (route engine, model selector, policy engine, observability layer), menelusuri alur intent extraction hingga tool invocation, dan terakhir memetakan posisi 9router di antara klien, LLM provider, serta downstream tools.

#Gambaran Besar Arsitektur 9router

Secara konseptual, 9router adalah rangkaian komponen yang bekerja seperti pabrik: request masuk di satu ujung, keputusan dibuat di tengah, dan pemanggilan model terjadi di ujung lain. Ada empat komponen inti yang membentuk pabrik tersebut:

Klien/App --> [Route Engine] --> [Policy Engine] --> [Model Selector]
                 ^                    ^                    |
                 |                    |                    v
            [Intent Extraction]   [Observability]    LLM Provider / Tools

Empat komponen inti adalah:

#Route Engine: Jantung Pengambilan Keputusan

Route engine adalah komponen yang menerima request pertama kali dan menjalankan routing decision pipeline. Ia mengekstrak informasi dari request (path, header, metadata, dan isi prompt), mengevaluasi aturan matching, lalu menentukan rute mana yang terpilih.

Bayangkan route engine seperti petugas informasi di bandara: ia menerima penumpang (request), menanyakan tujuan (intent), memeriksa identitas (user identity), lalu mengarahkan ke gerbang (route) yang benar. Keputusan ini bukan satu langkah, melainkan rantai evaluasi yang bisa dilihat di episode 4.

#Intent Extraction: Memahami Makna Request

Sebelum keputusan routing dibuat, 9router perlu memahami intent di balik request. Intent extraction mengubah prompt bahasa alami menjadi label yang bisa dievaluasi secara deterministik. Misalnya prompt "ringkas email ini" diekstrak menjadi intent summarization, sementara "buatkan gambar kucing" menjadi image-generation.

Dua pendekatan dipakai dalam intent extraction:

Pendekatan keyword cocok untuk request yang polanya jelas, sedangkan semantic classification menangani variasi bahasa yang luas. 9router memungkinkan keduanya digabungkan dalam satu pipeline, dengan semantic classifier sebagai pelengkap ketika keyword gagal.

#Model Selector: Memilih Model yang Tepat

Setelah rute ditentukan, model selector memilih model target yang paling sesuai. Keputusan ini mempertimbangkan kriteria seperti performance, cost, accuracy, dan availability provider. Model selector memahami stack model yang terdaftar — termasuk model conversation, embedding, code, dan vision — lalu memilih yang paling pas dengan task type dan policy yang berlaku.

Sebagai contoh, sebuah rute mungkin memilih antara tiga model untuk task summarization: model murah dan cepat untuk dokumen pendek, model premium untuk dokumen kompleks, dan fallback saat provider utama down. Model selector mengevaluasi kriteria ini dan menghasilkan keputusan yang bisa diaudit.

#Policy Engine: Aturan Bisnis dan Keamanan

Policy engine adalah lapisan yang memastikan setiap keputusan routing mematuhi kebijakan bisnis dan keamanan. Ia mengevaluasi hal-hal seperti: apakah pengguna ini boleh memakai model premium? Apakah region request ini mengizinkan provider tersebut? Apakah kuota bulanan sudah tercapai? Apakah isi prompt masuk kategori yang dilarang?

Policy engine bekerja sebelum model dipanggil. Jika sebuah request melanggar kebijakan, ia ditolak atau diarahkan ke fallback — bukan diteruskan ke model. Inilah yang membuat safety bisa diterapkan secara konsisten di satu lapisan, bukan di masing-masing aplikasi. Detail tentang enforcement, rate limiting, dan blocked intent akan dibahas mendalam di episode 6.

#Observability Layer: Mata dan Telinga Gateway

Setiap request yang melewati gateway meninggalkan jejak. Observability layer menangkap tiga jenis data: metrics (latency, request volume, success rate per rute), logs (konteks request, rute terpilih, hasil evaluasi policy), dan traces (perjalanan request dari klien hingga provider). Data ini menjadi bahan utama untuk memecahkan masalah dan mengoptimalkan routing di episode 7.

#Tool Invocation: Melampaui Pemanggilan Model

9router tidak hanya meneruskan request ke LLM; ia juga bisa memicu tool invocation — memanggil external tool atau service sebagai bagian dari alur agentic. Contohnya: setelah model menghasilkan jawaban, sebuah langkah memanggil API pencarian untuk mengambil data tambahan, lalu hasilnya dikirim balik ke model untuk penyusunan jawaban akhir.

Tool invocation adalah titik di mana gateway melewati batas "penerus traffic" dan menjadi orkestrator agentic. Inilah yang memungkinkan alur kerja yang lebih kompleks seperti retrieval-augmented generation dan function calling multi-langkah. Untuk mengikuti jejak setiap langkah secara langsung, gunakan perintah 9router logs --follow saat men-debug alur agentic.

#Posisi 9router di Antara Klien, Provider, dan Tools

Sekarang kita bisa memetakan posisi 9router dalam arsitektur lengkap. Ia berdiri di tiga persimpangan:

• Klien ke LLM provider: aplikasi mengirim satu request ke 9router, bukan ke banyak provider berbeda.
• Kebijakan ke pemanggilan model: setiap request lewat policy engine sebelum menyentuh model.
• Model ke tools: ketika model butuh data eksternal, 9router yang mengelola pemanggilan ke tools dan API services downstream.

Ilustrasi sederhananya seperti berikut:

   [Mobile/Web App] --> [9router] --> [OpenAI]
                              |--> [Anthropic]
                              |--> [Azure OpenAI]
                              `--> [Search API / Tools]

Konsekuensi dari desain ini besar: aplikasi hanya mengenal satu endpoint dan satu format API. Pergantian provider, perubahan model, atau penambahan policy tidak menyentuh kode aplikasi sama sekali — cukup ubah konfigurasi di gateway.

#Alur Lengkap Satu Request

Mari kita satukan semuanya dalam satu alur nyata. Ketika aplikasi mengirim request "ringkas dokumen ini" ke 9router:

1. Route engine menerima request dan mengekstrak metadata pengguna serta payload.
2. Intent extraction mengklasifikasikan prompt sebagai intent summarization.
3. Policy engine memeriksa izin akses, region, dan kuota pengguna.
4. Model selector memilih model ringkasan yang sesuai dengan tier pengguna.
5. Request diteruskan ke LLM provider yang dipilih.
6. Observability layer mencatat rute, model, latensi, dan hasil evaluasi policy.
7. Respons dikembalikan ke aplikasi lengkap dengan metadata routing.

Alur ini terjadi dalam hitungan milidetik dan meninggalkan jejak yang bisa diaudit kapan saja. Jika salah satu langkah gagal, fallback dan circuit breaker mengambil alih — topik yang akan kita bahas di fase-fase selanjutnya.

#Penutup

Di episode 2 ini kalian sudah membedah arsitektur internal 9router: empat komponen inti yang bekerja bersama, alur intent extraction hingga tool invocation, dan posisi gateway di antara klien, provider, serta tools. Pemahaman ini adalah fondasi untuk semua episode praktik berikutnya.

Inti yang harus dibawa pulang:

• Route engine menjalankan pipeline keputusan; intent extraction mengubah prompt menjadi label yang bisa dievaluasi.
• Model selector memilih model berdasarkan performance, cost, accuracy, dan availability.
• Policy engine memastikan setiap keputusan mematuhi aturan bisnis dan keamanan sebelum model dipanggil.
• Observability layer menangkap metrics, logs, dan traces untuk setiap keputusan routing.
• 9router berdiri di antara klien, LLM provider, dan tools — aplikasi hanya mengenal satu endpoint.

Di episode 3 selanjutnya kita akan menginstal 9router dan melakukan setup dasar — membuat workspace, mengonfigurasi route rules dan model endpoints pertama, lalu memverifikasi routing request dan response secara nyata. Siapkan emulator lokal kalian, karena kita mulai praktik!