Belajar 9router - Advanced Routing Patterns

#Pendahuluan

Episode 7 menutup observability: sekarang kalian bisa melihat route, model, dan provider dalam bentuk metrics, logs, dan traces. Data itu bukan tujuan akhir — ia bahan bakar untuk pola routing yang lebih cerdas.

Episode 8 mengajak kalian naik kelas ke advanced routing patterns. Kita bedah traffic splitting antar model atau tool pipeline, canary routes untuk rilis bertahap, shadowing untuk memvalidasi keputusan tanpa risiko, A/B testing pada route policy, dan dynamic routing yang bereaksi terhadap sinyal runtime. Setelah episode ini, konfigurasi kalian tidak lagi statis — ia bisa bermigrasi sendiri secara terkendali.

#Traffic Splitting

Traffic splitting membagi request yang sama persis ke beberapa target dengan persentase tertentu. Ini primitif dasar untuk semua pola lain: canary, shadowing, dan A/B semuanya dibangun di atas kemampuan memilah lalu lintas. Di 9router, splitting dideklarasikan langsung di route.

Split traffic 80/20 antar dua model

routes:
  - name: chat-split
    match:
      intent: chat
    split:
      - weight: 80
        target: gpt-4o-mini
      - weight: 20
        target: claude-3-5-sonnet

Kunci utama splitting adalah konsistensi: request dari pengguna yang sama sebaiknya selalu menuju target yang sama agar pengalaman tidak terasa tidak menentu. 9router mendukung consistent hashing berbasis key — misalnya user_id — sehingga user tertentu selalu dilayani model yang sama selama konfigurasi tidak berubah. Untuk meninjau weight split yang sedang aktif, 9router routes show --name chat-split menampilkan pembagian terkini.

Info

Consistent hashing tidak berlaku untuk distribusi acak murni. Kalau tujuan kalian hanya meratakan beban, gunakan split tanpa key; kalau ingin pengalaman konsisten per user, kunci split dengan identitas user.

#Canary Routes

Canary adalah strategi rilis: perkenalkan perubahan ke sebagian kecil traffic dulu, amati, lalu perluas bila aman. Untuk AI gateway, canary umumnya berupa model baru atau provider baru yang diuji di atas 5-10 persen traffic sebelum menggantikan target lama.

Canary 5% untuk model baru

routes:
  - name: chat-canary
    match:
      intent: chat
    split:
      - weight: 95
        target: gpt-4o-mini
      - weight: 5
        target: gpt-4o
    canary:
      enabled: true
      promote_on:
        success_rate_above: 0.99
        p95_latency_below_ms: 2000

Bagian canary berisi kondisi promosi: bila success rate di atas 99 persen dan p95 latency di bawah 2 detik selama periode pengamatan, 9router bisa menaikkan weight canary secara otomatis menuju 100 persen. Bila kondisi gagal, weight turun kembali ke nol — rollback otomatis tanpa deploy.

#Shadowing

Shadowing mengirim salinan request ke target bayangan tanpa mengubah respons asli. Pemanggil tetap menerima jawaban dari target utama, sementara 9router membandingkan hasil target bayangan di balik layar. Ini cara paling aman untuk memvalidasi model atau provider baru dengan traffic produksi asli.

Shadow route ke model percobaan

routes:
  - name: chat-shadow
    match:
      intent: chat
    target: gpt-4o-mini
    shadow:
      - target: gpt-4o
        sample: 1.0
        capture: [response, latency, tokens]

Perhatikan: target bayangan tidak pernah memengaruhi pengguna. Data shadowing dipakai untuk membandingkan kualitas jawaban, biaya, dan latency sebelum keputusan promosi dibuat. Ingat bahwa shadowing menggandakan biaya provider untuk traffic yang di-shadow, jadi batasi sampel atau durasi.

#A/B Testing pada Route Policy

A/B testing membawa eksperimen ke ranah policy, bukan hanya model. Kalian ingin tahu apakah policy baru — misalnya matcher intent yang lebih agresif — menghasilkan keputusan yang lebih baik dari policy lama. 9router memungkinkan dua varian policy dijalankan bersamaan dengan pembagian deterministik per user.

A/B test dua varian policy

experiments:
  - name: strict-vs-loose-filter
    key: user_id
    variants:
      - name: control
        weight: 50
        config_file: policies/strict.yaml
      - name: treatment
        weight: 50
        config_file: policies/loose.yaml

Hasil tiap varian diberi label eksperimen di metrics dan logs — ingat episode 7. Kalian lalu membandingkan success rate, latency, dan biaya antar varian dari data observability yang sudah terpisah. Untuk memantau progres, 9router experiments status menampilkan jumlah request tiap varian dan metrik ringkasnya. Begitu salah satu varian terbukti unggul, promosikan varian itu menjadi policy default dan hentikan eksperimen.

#Dynamic Routing Berbasis Sinyal Runtime

Pola paling dinamis: routing yang berubah mengikuti kondisi runtime, bukan konfigurasi statis. 9router mendukung keputusan berdasarkan sinyal yang dihitung saat runtime, seperti beban antrean provider, latency observasi terkini, biaya token, atau status health provider. Ini memungkinkan gateway memilih jalur terbaik untuk setiap momen.

Dynamic routing berdasar health dan latency

routes:
  - name: chat-dynamic
    match:
      intent: chat
    dynamic:
      - target: openai/gpt-4o-mini
        when: provider_healthy(openai) and p95_latency(openai) < 1500
      - target: anthropic/claude-3-5-sonnet
        when: not provider_healthy(openai)
      - target: azure/openai-eu
        when: region == "eu"

Bila provider OpenAI sehat dan cepat, traffic mengalir ke sana; saat provider tumbang, route berpindah ke Anthropic; dan request dari Eropa selalu diarahkan ke instance Azure di region EU. Evaluasi dilakukan per request menggunakan sinyal real-time sehingga gateway bisa merespons gangguan dalam hitungan detik, bukan menit.

Warning

Dynamic routing bergantung pada kualitas sinyal. Pastikan metrics yang dijadikan dasar keputusan (latency, health) sudah benar-benar akurat dan ter-update, karena keputusan salah input berarti routing salah output.

#Penutup

Advanced routing patterns mengubah 9router dari penerus request statis menjadi sistem yang belajar dan beradaptasi. Traffic splitting menjadi fondasi, canary memberikan rilis bertahap dengan promosi otomatis, shadowing memvalidasi tanpa risiko, A/B testing membuat keputusan policy berbasis data, dan dynamic routing merespons kondisi runtime secara langsung. Kombinasi pattern ini membuat gateway kalian lebih gesit tanpa kehilangan kendali.

Inti yang harus dibawa pulang:

Traffic splitting adalah primitif dasar; kunci dengan identitas user bila ingin pengalaman konsisten.
Canary route mempromosikan perubahan bertahap dan bisa rollback otomatis saat kondisi target gagal.
Shadowing memvalidasi model baru dengan traffic produksi tanpa mengubah respons pengguna.
A/B testing pada policy membutuhkan label eksperimen di metrics dan logs untuk perbandingan yang bersih.
Dynamic routing menilai sinyal real-time per request; kualitas keputusan mengikuti kualitas sinyal.

Di episode 9 kita berurusan dengan banyak pelanggan sekaligus: Multi-tenant & Customer-specific Routing — tenant-aware route rules, per-customer model preferences, isolasi workload sensitif, hingga SLAs yang berbeda-beda. Sampai jumpa!